Rethink by Buildout is a managed package in your own Salesforce org, which means you can extend it with everything the platform offers — and means Buildout ships new versions your code has to survive. Twopir Consulting builds alongside the package, in your namespace, never inside theirs. Apex, LWC, API integrations. Upgrade-safe by construction.
Trusted by 500+ organizations — including property and real estate businesses running their operations on Salesforce with Twopir Consulting.
Build & Integration Practice
Every one of these is solvable. The question is which tier solves it, and what that tier costs you in upgrade obligation — which is the rest of this page.
Split fields exist on the associated parties. Tiered splits, rolling thresholds, referral fees off the top and desk overrides do not calculate themselves — that is Flow at the simple end and Apex once the rules interact.
Commission invoices are raised in Rethink. Getting them into the accounting or ERP system — and revenue recognition back out — is an API build or middleware, because no packaged connector covers it.
Standard record pages are generic by necessity. A tour-scheduling screen, a one-pass deal-update view, or a stacking plan with your own leasing logic are Lightning Web Components, not layout changes.
Debt schedules on an asset, capital partners against a deal, construction milestones, CAM reconciliation. Custom objects alongside TTL_Core — related to Property or Deal, reportable, and untouched by package releases.
Listing agreements, LOIs, proposals and commission invoices generated from deal and property data. Rethink holds the data; the document engine is a separate tool that has to be wired to the right fields and locked against edits.
Showcase accepts custom fields only in a limited set of types. A formula or picklist you assumed would publish simply will not, and you find out after the listing team has been told it works. Field types are a design decision, not an afterthought.
Every requirement can be met at more than one tier. The cheapest build is rarely the cheapest decision — what you are really choosing is who maintains it, and for how long.
| Tier | What it covers | Upgrade obligation | Choose it when |
|---|---|---|---|
| 1 · Declarative config | Record types, page layouts, stages, validation rules, Action Plan templates, reports, dashboards, sharing rules. | None. Carries forward across package releases. | Always try here first. Most real requirements land in this tier, and admins can maintain it without a developer. |
| 2 · Flow | Record-triggered and screen automation: routing, task generation, field derivation, approval chains, guided data entry. | Low. Test on upgrade if the Flow reads package fields or depends on package automation order. | The logic is expressible without code and an admin will own it. Most automation belongs here. |
| 3 · Apex & LWC | Custom objects, trigger logic, batch and scheduled jobs, platform events, and Lightning Web Components for broker-specific screens. | Real. Owned code, tested against each package release, with test coverage that must keep passing. | The requirement genuinely exceeds Flow — complex calculation, bulk volume, or a screen that does not exist. |
| 4 · External integration | REST and Bulk API builds, middleware and iPaaS flows, webhooks, and the data contracts between Rethink and other systems. | Real, and shared. Both sides can change. Versioned contracts and monitoring are part of the build, not extras. | The data lives in another system of record and has to stay consistent in both. |
There is no tier five. Modifying components inside the managed package is not on this list because we do not do it — those components are Buildout's to change, and editing them is how a brokerage ends up unable to upgrade at all.
Everything below is tier 3 or tier 4 work. If your requirement can be met at tier 1 or 2 we will tell you, and build it there instead — that conversation is part of the engagement.
The CRE data the package has no home for, modelled properly alongside TTL_Core so it reports and shares like everything else.
Calculation and orchestration that Flow cannot carry — written bulk-safe, tested, and documented for whoever maintains it next.
Screens shaped like the job, not like the object. Built on the same data, so nothing goes out of sync with the record.
Real data contracts between Rethink and the systems that hold the rest of your business — built to be monitored, not just to pass a demo.
Contract-critical documents generated from the record, with the fields that matter locked so a typo cannot reach a counterparty.
The work that keeps everything above from becoming a liability. Unglamorous, and the reason customised orgs stay upgradeable.
An integration is a data contract, not a switch. Every one below is specified the same way: both systems named, what moves, in which direction, and which team consumes it.
| Rethink record | Showcase record | Direction | Key fields carried |
|---|---|---|---|
| Property | Listing | Two-way | Buildout Id, name, address, building size, total price to sale price |
| Deal Pipeline | Listing | Two-way | Lead broker to primary broker; associated parties to additional brokers |
| Space / Unit | Lease Space | Two-way | Space name, size, rent amount to lease rate, date available, lease expiration, floor number |
| Sale Comp | Sale Comp | Two-way | Address, pricing, cap rate |
| Lease Comp | Lease Comp | Two-way | Lease commencement, lease term in months, rent |
| Inquiry | Lead | Showcase → Rethink only | Lead contact and inquiry detail, delivered instantly |
1 · An internal associated party is required. A property or deal with no internal broker attached will not send to Showcase. Nothing errors — the record simply never leaves the org, which is why this is the single most common "our listings are not updating" ticket.
2 · Records must match on Buildout Id or an exact address under the same lead broker. Near-matches do not resolve, so address hygiene is an integration requirement rather than a data-quality nicety.
3 · Custom fields sync only in supported types. Text, number, checkbox, percentage and date. Design a formula or an unsupported picklist into a published field and it will never appear on the listing — decide field types during design, not after.
4 · Direction is not symmetrical. Showcase to Rethink is instant. Rethink to Showcase runs on the Send to Buildout action or on a schedule. Teams that assume both directions are instant will report the integration as broken when it is merely scheduled.
Commission invoices raised in Rethink flow to the finance system as receivables; payment status and recognised revenue flow back onto the deal. Finance stops rebuilding the commission schedule in a spreadsheet, and brokers can see what has actually been paid. Almost always an API or middleware build rather than a packaged connector, so scope it in design rather than discovering it in build.
Deal and property data drives listing agreements, LOIs, proposals and commission invoices. Nintex DocGen, S-Docs and Conga-class engines all sit naturally on the Deal object. The design work is deciding which fields are contract-critical and locking them, so a document cannot be produced from a half-populated record.
DocuSign or Adobe Sign wired to the lease-execution and offer stages. The integration that matters is not sending the envelope — it is writing completion back as a reportable field so the deal advances on execution, and operations can see what is outstanding without opening a separate console.
Outlook, Gmail and Google Workspace activity captured against companies, contacts, properties and deals via Einstein Activity Capture or a tool such as Cirrus Insight. This is what makes the landlord activity report truthful: without it, the report reflects what brokers remembered to log rather than what happened.
RingCentral, Dialpad, PhoneIQ, PhoneBurner and SMS platforms connected to prospecting lists, with call and message activity written back to the record. The integration turns a list into a measurable outreach programme — without the write-back, you have a dialler and no data.
Property and contact segments pushed to HubSpot, Marketo, Account Engagement or a Mailchimp-class tool, with engagement flowing back onto the contact. The architecture question is not the connector — it is which system owns consent and suppression. Salesforce holds the CRE relationship and the marketing platform holds the engagement history, so one of them must be authoritative for opt-out or you will eventually email someone who unsubscribed. Decide it before the first send, and enforce it in the sync rather than in a process document.
Buildout ships new versions of the managed package. Treated properly an upgrade is a routine maintenance window; treated casually it is how firms end up two years behind and afraid to move.
Custom objects, fields, code and components live in your own namespace and metadata — never entangled with TTL_Core. Separation is a build-time decision, not something that can be retrofitted once a release breaks.
The upgrade is applied and exercised in a sandbox before production, with particular attention to anything that reads package fields or depends on package automation firing in a given order — the two things most likely to shift between versions.
Every customisation, what it does, which package objects and fields it touches, and why it exists. This is what lets a regression check be targeted rather than a full re-test, and it is what makes handover to your own team possible.
Metadata in version control, deployments scripted and repeatable. You can see what changed, when and by whom — and roll forward deliberately rather than reconstructing a production org from memory.
We do not modify the managed package. Components inside TTL_Core belong to Buildout. Editing them — where the platform even permits it — converts every future
release into a migration project, and it is the single fastest way to make an org unsupportable.
We do not build at tier 3 what tier 1 can do. Custom code has a maintenance cost that lasts as long as the org does. If a requirement can be met with a validation rule and a layout change, that is the recommendation you will get, even though it is smaller work for us.
We do not leave you unable to change it yourself. Handover documentation your own admin can work from is part of delivery. An integration only we can maintain is a dependency, and you should not want one.
Two kinds of evidence, labelled: what Buildout has published about the product, and what Twopir has delivered on Salesforce for operations teams.
Buildout's own customer story on Rethink CRM, cited here as product evidence — VREI is Buildout's customer, not a Twopir engagement.
Consolidation is the point. Every integration on this page exists to keep one record authoritative instead of asking people to reconcile two.
Read Buildout's customer storyRebuilding lead management and sales operations on Salesforce, including the integration layer underneath it.
The transferable part is the discipline: data contracts specified before build, failures surfaced through error queues rather than discovered by a user, and nothing left that only the original developer understands.
Read the case studyRepresentative engagement shapes, not measured client results — included so you can place your own requirement on the tier table above.
Presented as a development request. It was an approval process and two validation rules — no code, no upgrade obligation, and the firm's own admin now maintains it. Always worth checking before quoting a build.
Flow could express one tier, not the interaction between four plus an off-the-top referral fee. Apex, bulk-safe, tested, with the rules held in custom metadata so rate changes do not require a deployment.
An API build to the accounting system with idempotent handling and an error queue. The decisive design question was not the connector but which system is authoritative for an invoice once both hold one.
Custom development is the most profitable thing a consultancy can sell and the most expensive thing a client can own. Those two facts should make you read any build recommendation carefully.
If a validation rule and a layout change solve it, that is the recommendation — even though it is smaller work for us. The tier table exists so you can hold us to that rather than take it on trust.
Bulkification, governor limits, trigger frameworks, sharing recalculation, release management. Rethink is a managed package on a platform we have worked on for over a decade — which matters most exactly when a requirement stops being standard.
Your namespace, source control, a written customisation inventory, sandbox-first releases. The reason it survives a package upgrade is structural, not a commitment to be careful.
Idempotent handling, retries, error queues and alerting. An integration that fails loudly is a support ticket; one that fails silently is a data-integrity incident you discover months later in a report nobody trusts any more.
Documented, source-controlled, handed over to your admin or in-house developer. We would rather be re-engaged because the work was good than retained because nobody else can read it.
No, and you should not want anyone to. Components inside the TTL_Core namespace belong to Buildout. Where the platform permits editing them at all, doing so converts every future package release into a migration project and is the fastest way to make an org unsupportable. Everything we build sits alongside the package in your own namespace — custom objects, fields, code and components that a package upgrade does not touch.
Configuration carries forward with no obligation at all. Custom code and integrations are the part that needs managing, which is exactly why we keep them separate from the package rather than entangled with it. Our standard practice is to apply and exercise each upgrade in a sandbox first, paying particular attention to anything that reads package fields or depends on package automation firing in a given order. Handled that way an upgrade is a routine maintenance window rather than a project.
Flow whenever the logic can be expressed without code and an administrator will own it — which covers most automation, and keeps the change in the hands of the people closest to the business. Apex when the requirement genuinely exceeds that: complex calculation where rules interact, bulk volume where governor limits matter, or orchestration that needs to be retry-safe. The deciding question is rarely "can Flow do this" — it is who will maintain it in two years, and whether that person writes code.
Yes, and it is usually an API or middleware build rather than a packaged connector, so it should be scoped during design rather than discovered during build. Commission invoices raised in Rethink flow out as receivables; payment status and recognised revenue flow back onto the deal. The design decisions that matter are which system is authoritative for an invoice once both hold one, how failures are surfaced, and how the contract is versioned so either side can change without breaking the other.
Yes — this is one of the real advantages of a CRE CRM that lives inside Salesforce. Debt schedules, capital partners, construction milestones, CAM reconciliation: all can be custom objects related to Property, Space or Deal, reportable alongside package data and unaffected by package releases. The work worth doing carefully is the relationship design and the sharing model, because an object that reports beautifully but shares wrongly is worse than no object at all. One caveat: custom fields sync to Buildout Showcase only in supported types, so anything you intend to publish needs its field type decided during design.
Yes. Buildout lists HubSpot, Marketo, Account Engagement and Mailchimp-class tools among Rethink's integrations, and property and contact segments can be pushed out with engagement flowing back onto the contact. The architecture question is not the connector though — it is which system owns consent and suppression. Salesforce holds the CRE relationship, the marketing platform holds the engagement history, and exactly one of them has to be authoritative for opt-out or you will eventually email somebody who unsubscribed. Decide that before the first send, and enforce it in the sync rather than in a process document nobody reads.
You own it. It lives in your org and your source control, with a written inventory of every customisation, what it does, which package objects and fields it touches, and why it exists. Handover documentation your own admin or developer can work from is part of delivery rather than an extra. An integration that only we can maintain is a dependency we do not think you should accept, and we would rather be re-engaged because the work was good than retained because nobody else can read it.
The main product page: what Rethink by Buildout is, who it is for, and how far it can be pushed.
SiblingScope, migration sequencing and delivery phases for a first rollout or a replatform.
SiblingThe manual work still happening after go-live, and the automation patterns that remove it.
SiblingWhat Agentforce can do with CRE data once the operating data underneath it is trustworthy.
Parent ServiceThe practice-level view across CRM, operations and reporting for a CRE business.
Next StepBring us a requirement you are not sure is possible. We will tell you which tier it lands in.
Most of them are possible. The useful conversation is which of the four tiers solves it, what that costs you on every future package release, and whether the lowest tier would have done.
Salesforce architects who will quote you the lowest tier that works
