Your CRE deals run on Rethink. We make the system run on your brokerage.

Effectively yes. The Salesforce-native CRE CRM was called REthink CRE before Buildout acquired it, and is marketed today as Rethink by Buildout. Buildout CRM is the broader CRM offering Buildout markets around it. If you are running the managed package inside your own Salesforce org, you are running the product this page describes, whichever name your contract uses.

Both are viable and we build both, so we will tell you honestly which fits. Rethink gives you a CRE data model, four representation pipelines, comps, GEOsearch and the Showcase connection without building them — which is a large head start if your business is brokerage. Building on standard Salesforce objects makes more sense when your model is unusual enough that you would be fighting the package, or when CRE is one line of business inside a much larger org. The deciding question is usually whether you need the Buildout marketing connection, not whether Salesforce can technically do it.

Three things drive the timeline: how many desks and offices you run, how clean your existing property and contact data is, and how many systems have to exchange data with the org. Data quality is usually the biggest variable by a wide margin. From your side we need a decision-maker per representation type who can sign off on stages, someone who owns commission rules, and access to whatever currently holds the data. We scope the schedule in the audit phase rather than quoting a number before seeing the org — a fixed timeline offered before that is a guess.

Configuration covers everything achievable without code — stages, record types, page layouts, validation rules, Action Plan templates, reports, dashboards, sharing and most Flow automation. Custom development begins when a requirement needs Apex, a Lightning Web Component, an external API, or data structures the package does not provide. The practical difference is the upgrade obligation: configuration is upgrade-safe, custom code has to be maintained across package releases. We never modify the managed package itself — we build alongside it in your own namespace.

Yes, and the sequence matters more than the tooling. Companies load before contacts, because a contact cannot be saved without a parent company. Properties load before spaces, because spaces are children of a property and are deleted with it. Owners have to be resolved to the right company or contact record or the ownership view is wrong from day one. Historical comps are worth loading even when they feel optional — they are what makes GEOsearch and your pitch material useful immediately rather than in two years. Every migration is rehearsed in a sandbox and reconciled before it touches production.

Configuration carries forward. Custom code and integrations are the part that needs managing, which is why we keep them in your own namespace and metadata rather than entangled with the package. Our standard practice is to test upgrades in a sandbox before production, with particular attention to anything that reads package fields or depends on package automation firing in a given order. Treated this way an upgrade is a routine maintenance window; treated casually it is how brokerages end up afraid to upgrade at all.

Yes — that is one of the practical advantages of a CRE CRM that lives inside Salesforce rather than outside it. Agentforce is a Salesforce platform capability, so it reads the same records, respects the same sharing model and runs against your Deals, Properties and Inquiries like any other data. The prerequisite is unglamorous: agents are only as good as the data model underneath them, so the comp and pipeline hygiene described on this page comes first. We scope AI work after the operating data is trustworthy, never before.