MLS boards, portals, the IDX site, a transaction platform, an accounting ledger and a marketing tool — each one true about part of a deal and none of them talking. Twopir Consulting designs the data flows between Propertybase and the rest of your stack, owns the reconciliation, and builds the integration where no connector exists. One record of truth, with a direction and an owner for every field on it.
Trusted by 500+ organizations — including brokerages, property managers and real estate investment groups whose MLS feeds, portals, transaction platforms and ledgers Twopir Consulting keeps in agreement with each other.
Systems We Connect
Almost every brokerage we audit has integrations. What it does not have is a direction, an owner and a reconciliation rule for each one. An integration nobody watches is a manual process with extra steps.
A credential expires, a board renames a field, a nightly job silently stops. Nothing alerts, because nothing was built to. The first person to find out is an agent calling a buyer about a property that went under contract on Tuesday.
Both systems can write the same field, so both do. A price edited in the CRM is overwritten by the feed, or the feed is overwritten by the office. Nobody can say which one is authoritative, so agents trust neither and phone the listing agent instead.
Matching on address, or on a listing number the MLS reissues, produces duplicates on every sync. Within a quarter the same property exists three times, each with a different status, and reporting on inventory becomes guesswork.
A record fails validation and the integration logs it somewhere nobody reads. The sync reports success, the count is short by forty, and the gap only becomes visible when a commission does not calculate at month end.
Offers, milestones and documents live in the loop; the deal record in Propertybase stops at "under contract". Coordinators keep both current by hand, and leadership reporting reflects whichever one somebody updated last.
The pipeline says one thing, the ledger another, and the difference is explained monthly in a meeting rather than eliminated in a system. Splits get recalculated by hand, agents question their statements, and trust erodes every cycle.
Propertybase integration is the work of deciding, for every field that exists in more than one system, which system owns it, which direction it moves, how often, what happens when the two disagree, and who is told when the flow stops. The connector is the easy part. Propertybase already ships MLS and IDX synchronisation and portal publishing — vendor documentation covers the portal feed, field mapping and syndication setup at help.propertybase.com — and because the data lands in a Salesforce org, everything else connects the way any Salesforce integration does.
One vendor requirement shapes every listing integration: each listing record needs a unique, never-changing identifier — a broker listing ID or MLS ID — for portals and feeds to key against. Firms that skip it match on address instead, and duplicate their inventory within a quarter. Getting the key right at design time is cheaper than every deduplication project that follows.
Who this is for: operations leaders, CRM managers and technology leads at firms where Propertybase is live but the systems around it are not joined up. We help growing and mid-market companies solve complex CRM, integration, and business system challenges, and we work with enterprise organizations facing the same problems at greater scale. If you are a developer looking for the API surface itself — REST and Bulk, platform events, authentication, rate limits and retry behaviour — that is a different page: Propertybase API & integrations.
The three ways a system connects to Propertybase, and what each one costs to own
| Native to the org | Packaged or middleware connector | Built integration | |
|---|---|---|---|
| What it is | The other application installs into the same Salesforce org, so there is no integration at all — only shared records | A vendor connector or an integration platform moves data between two systems on a schedule or a trigger | Apex, platform events or REST written against both APIs, for a system with no connector worth using |
| Typical example | Accounting Seed posting commission and invoice records from a closed transaction | MLS and IDX feeds, DocuSign, Dotloop, QuickBooks or Xero, Marketing Cloud | A proprietary back-office ledger, a regional portal, or a valuation service with no listing on AppExchange |
| Cost to own | Lowest — no moving parts between systems, and one security model | Moderate — the connector is maintained for you, but mapping, volume limits and failure handling are yours | Highest — you own the code, the retries, the monitoring and every API change at the far end |
| When we recommend it | Whenever a credible native option exists, even if it means changing a back-office tool | The default for the well-served integrations, where a supported connector is genuinely maintained | Only when the first two cannot express the requirement — never because building is faster this quarter |
Most brokerages arrive expecting column three and leave with columns one and two. Building is the most expensive answer and the easiest one to sell, which is why we scope it last — see Propertybase customization for where custom development genuinely earns its place.
"We need an integration" is three different projects. Most firms ask for the first, need the second, and only stop having the same conversation once they have the third.
Standing up a flow that does not exist yet: a new MLS board, a portal, a transaction platform, an accounting ledger. Scoped per system, delivered against a mapping document you sign before anything moves.
Fixing flows that already exist and cannot be trusted. Duplicate inventory, stale statuses, records that vanish between systems, counts that never agree. We find where the data diverges before we change anything.
Making the whole estate observable, so a broken flow announces itself instead of being discovered. This is the difference between integrations that work and integrations that keep working.
A large share of integration work never needs code. Propertybase ships MLS, IDX and portal synchronisation, and inside your own Salesforce org you can express field mapping, validation rules, scheduled Flows, matching logic and alerting declaratively — all of it upgrade-safe, because it lives in your namespace rather than the managed package's. That surface covers more requirements than most firms expect, and it is where we start every time.
Custom development enters at three predictable places: a bi-directional sync with a system that has no connector worth using, a transformation too stateful for Flow to express safely at volume, and a matching or valuation rule the Listing Browser cannot reach. Those are engineering, we scope them as engineering, and the API-level detail lives on Propertybase API & integrations. Everything else we solve with clicks, because clicks cost less to build and far less to own.
Ordered the way a brokerage feels the pain. Listing data first, because everything downstream is wrong if inventory is wrong; finance last, because it cannot be right until the deal record is.
The feed that everything else depends on. Multiple boards, different field conventions, and a status model that has to reconcile rather than overwrite.
Listings out to the portals, inquiries back with the source stamped. Two directions, two different failure modes, one identifier tying them together.
Offer to close, kept in one place. Milestone dates, document completion and execution status write back onto the deal record so nobody maintains two systems by hand.
Where the pipeline and the ledger stop disagreeing. Native inside the org where the accounting application allows it, bi-directional where the ledger stays outside.
Inquiry criteria and listing activity out to build segments; engagement and campaign response back onto the contact, so agents see intent before they pick up the phone.
The workstream that is always cut and always regretted. An integration estate nobody can observe will fail silently, and the cost lands on whoever is holding a deal that day.
This is the artefact an integration engagement actually produces. Each row names both systems, what moves, which way it moves, and who reads it — because an integration with no named consumer is one nobody will notice failing.
Listings, price changes, status and media flow MLS → Propertybase on a scheduled feed; office-originated listings flow back out. Agents and coordinators consume it, and it is the flow whose failure is felt fastest.
Listings syndicate outward against a stable broker listing ID; inquiries return as Inquiry records with the portal stamped. Marketing consumes it, and it is what makes cost per closing measurable by portal.
Transaction status, milestone dates and document completion sync back onto the deal record. Coordinators and team leads consume it; without it the CRM stops being true the moment an offer is accepted.
Listing agreements, buyer representation and disclosures send from the record and write execution status back, so a signed agreement advances the stage automatically. Compliance consumes the audit trail.
Native to the same org, so a closed transaction posts commission and invoice records with no integration at all. Finance and operations read one set of numbers — the cheapest architecture available here.
Disbursements, agent payables and invoices sync bi-directionally where the ledger stays outside Salesforce. The back office consumes it, and month-end close stops depending on a manual export.
Inquiry criteria and listing activity flow out to build segments; engagement and campaign response flow back onto the contact. Agents consume it as intent signal before a first call.
Reads the same Propertybase records to score inquiries and draft follow-up, then writes activity back. Grounded in your listing and deal data, which is only worth doing once the flows above are trustworthy.
The technical surface underneath — REST and Bulk, platform events, middleware, auth and retry behaviour — is documented on Propertybase API & integrations; the wider architecture across sales, marketing and finance is revenue operations.
Integration disputes are almost always disputes about what was agreed. Stage two ends with a document that names every field, its direction and its owner — and nothing gets built until somebody on your side has signed it.
Every system that holds a record about a listing, a person or a deal, and what each one is currently authoritative for. Where flows already exist we measure the divergence rather than trusting the documentation — the gap between the two is usually the scope.
Field by field: which system owns it, which direction it moves, how often, what wins on conflict, and what happens on failure. Record keys are decided here, because matching on address is what produces duplicate inventory later. You sign this before we build.
Native first, connector second, custom code only where the first two cannot express the requirement. Built and run repeatedly against real data volumes in a sandbox, including the failure paths — a sync that has never been tested failing is a sync that will fail badly.
First full sync in production, reconciled by count against the source, with discrepancies resolved before the flow is trusted. Where a manual process is being replaced, both run in parallel until the numbers agree — nobody switches off the spreadsheet on faith.
Health checks, error queues and alerting to a named owner, plus a written runbook per flow. The test of a finished integration engagement is that your team can diagnose a failed sync without calling us — and knows within minutes that one happened.
Two engagements, both real estate, both starting from software the client already owned and could not reconcile. The numbers are the ones those clients measured — scoped exactly as they measured them.
We had Salesforce. We had Propertybase. We had agents using three different follow-up tools. Nothing was connected, and our managing broker was flying blind. Twopir came in, mapped everything, and built a single operating model that our entire team actually uses. We went from not knowing where deals were to having a live dashboard that tells us exactly what's open, what's at risk, and what closed last week.
MLS and portal synchronisation rebuilt against stable listing keys, with health-check automation on every feed.
Commission reconciliation used to take our back office three full days at the end of every month. Agents were questioning their splits, and we had no clean audit trail. Twopir connected our deal records to Accounting Seed and built automated disbursement workflows. We now close commission statements the same day a transaction closes. The trust that has rebuilt with our agents because of that alone has been significant.
Deal records connected to the accounting ledger — commission and disbursement posting without re-entry.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner. We resell none of the systems in your integration map, which is why we can tell you that the cheapest answer to a requirement is often to change a back-office tool rather than to build a bridge to it.
Direction, authority, frequency, conflict rule and failure behaviour, agreed field by field and signed off. Integrations that go wrong in month six went wrong at this stage, when nobody wrote down who owns the price field.
Building is the most expensive answer and the easiest one to sell. We recommend it only when the supported options genuinely cannot express the requirement — and we say which of the three you are getting before the statement of work.
Health checks, error queues, retries and an alert to a named person. An integration nobody can observe is a manual process with extra steps, and it will be discovered by an agent rather than by the operations team.
Multiple boards with different field conventions, media that has to survive each sync, statuses that reconcile rather than overwrite, and a stable listing identifier on every record. These are the details that decide whether inventory stays trustworthy.
Lead routing, transaction coordination and commission reconciliation are one system, not three projects. That is why an improvement in agent follow-up shows up in the commission data rather than disappearing between two tools.
MLS and IDX synchronisation and portal publishing are part of the product itself. Beyond that, because the data sits in a Salesforce org, the rest of the stack connects the way any Salesforce integration does. In practice that means portal inquiries from Zillow and Realtor.com arriving as Inquiry records with the source stamped, Dotloop transaction status syncing back onto the deal record, DocuSign writing execution status against listing agreements, Accounting Seed posting commission and invoice records natively in the same org, QuickBooks or Xero syncing disbursements bi-directionally, and Marketing Cloud or Account Engagement exchanging segment and engagement data. Where a system has no connector worth using, we build the integration.
Audience, not topic. This page is for operations and CRM leaders deciding which business systems should be connected, in which direction, and who owns each flow when it breaks — the data contract. The Propertybase API and integrations page is for developers and technical architects working with the surface underneath: Salesforce REST and Bulk APIs, platform events, RESO Web API and RETS feeds, middleware platforms, authentication, rate limits, retry and error handling. If you are choosing what to connect, start here. If you are building against it, start there.
Yes, and multi-board firms are where the mapping work actually lives. Each board publishes its own field conventions, status vocabulary and media rules, so a mapping that works for one will quietly mangle another — statuses that mean "withdrawn" in one board and "temporarily off market" in the next are the classic case. We map per board rather than per firm, reconcile the status models into one lifecycle your reporting can use, and give every listing a unique, never-changing identifier so the same property does not arrive twice from two boards.
Almost always, yes. Duplication at this scale nearly always has one cause: records were matched on something unstable, usually an address or a reissued listing number, instead of on a unique, never-changing identifier. Fixing it is a three-part job — assign proper keys retroactively, merge the existing duplicates under rules that preserve the right history, then correct the matching logic so the next sync does not recreate them. Deduplicating without that third step is the mistake firms make twice; the duplicates come back within a quarter.
In this order of preference: native, then connector, then built. Native means the other application installs into the same Salesforce org, so there is no integration at all and nothing to maintain — Accounting Seed is the common example. A packaged or middleware connector is the right default for the well-served flows, because somebody else maintains it as both APIs change. A built integration is the most expensive answer to own: you carry the code, the retries, the monitoring and every API change at the far end. We recommend building only when the first two genuinely cannot express the requirement, never because it is faster this quarter.
Only if somebody built the alerting, and most firms have not. The failure mode that costs money is not a sync that stops — it is a sync that reports success while dropping records that failed validation. We ship every flow with a scheduled health check, an error queue that retries rather than discards, volume monitoring so a truncated sync is visible, and alerting to a named owner rather than to a log nobody reads. The measure of a finished engagement is that your team knows within minutes, and can diagnose it from a runbook without calling us.
Yes, when they are built in the supported way. Propertybase ships in its own namespace and its code and components are locked, but everything you build in your own org — custom fields on the packaged objects, validation rules, Flows, Apex, mapping configuration and alerting — lives in your namespace and survives an upgrade. What does need testing at each release is anything that reads a packaged field the vendor may change, which is why we keep a sandbox on the upgrade path and run the integration test set there before production takes a new version.
A feed that stopped, inventory that duplicated, a ledger that never agrees with the pipeline, or a system with no connector at all. We will tell you whether it is a mapping problem, a monitoring problem or a genuine build — before anyone writes a proposal.
Salesforce architecture, Propertybase delivery & real estate operations
