A Propertybase implementation is a Salesforce org build, an MLS and IDX feed connection, a data migration with history intact, and a cutover your agents can survive. Twopir Consulting runs all four as one engagement — five phases, sandbox-validated, with a schedule that comes out of the audit rather than out of a template. Day one your agents log into their listings, not an empty org.
Trusted by 500+ organizations — including brokerages, property managers and real estate investment groups who came to Twopir Consulting for a first Propertybase build, or for the rebuild after one that did not land.
What a Build Touches
Failed Propertybase implementations rarely fail technically. They fail on the six things below — each of which is a decision somebody had to make and nobody owned. The client in our case study had already been through two of them.
Packaged Listing, Property and Inquiry objects get accepted as-is, offices and teams are mapped to whatever the installer defaulted to, and six months later a reporting requirement needs a sharing model nobody can retrofit without a rebuild.
Contacts move, deal history does not. Agents lose the record of every conversation they had with a past client, decide the new system is worse than the old one, and the brokerage never recovers the adoption it lost in week one.
The first full sync works, so the feed is signed off. Nothing watches it afterwards. When a board changes a field or a credential expires, listings quietly stop updating and the first person to notice is an agent calling a buyer about a property already under contract.
A week count quoted from a template collides with real listing volume, real feed complexity and real data quality. Scope gets cut to protect the date, and what gets cut is always training, testing and the reporting layer leadership was buying the system for.
Everyone sits through the same two-hour session covering every object. Agents leave knowing what Propertybase is and not how to work a lead in it, coordinators never see their own milestone workflow, and the back office finds out about commission automation at month end.
The old system is switched off on a Friday. On Monday every unmapped field, every broken automation and every missing document surfaces at once, in production, with agents watching. A phased parallel run costs two weeks and prevents exactly this.
A Propertybase implementation is the work of turning a Salesforce org and a managed package into a brokerage's operating system. Five things happen, in this order: a Salesforce org is set up with a real environment strategy, the Propertybase package is installed and its objects mapped to how the firm actually works, MLS and IDX feeds are connected and reconciled, existing CRM data is migrated with history intact, and users, roles and record-level sharing are configured by office and team. Rollout and training follow. Propertybase is sold today as Propertybase powered by Lone Wolf and is still widely searched under its longstanding name, Propertybase Salesforce Edition; vendor documentation lives at help.propertybase.com.
The part that decides whether the project succeeds is the second one. Propertybase ships Property, Listing and Inquiry as real Salesforce objects, and a Listing is always based on Property data — creating a Listing for a property that does not yet exist creates the Property record behind it. How offices, teams and agents sit above those objects, and who can see whose records, is a design decision made once and lived with for years. An implementation that skips it is not faster; it is borrowing time from the rebuild.
Who this is for: brokerages, franchises and property teams standing Propertybase up for the first time, replacing a CRM that has been outgrown, or restarting after an implementation that did not land. 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 an out-of-the-box agent CRM would meet your requirements, the Salesforce Platform underneath Propertybase is capability you will pay for and not use — and we will say so during the audit rather than after the invoice.
What sits inside a Propertybase implementation, what comes after it, and what is never ours to sell
| In the implementation | A separate engagement | Not sold by Twopir | |
|---|---|---|---|
| Platform | Org setup, environment strategy, package install and post-install configuration | Ongoing package upgrade testing and release management | Salesforce platform licences and Propertybase licences — both come from the vendors |
| Data | Migration from the current CRM with deal and activity history preserved, plus deduplication | Archival of systems the migration does not cover, and long-run data quality programmes | MLS board membership and feed entitlement — held by your firm, not by us |
| Automation | Lead routing, SLA clocks, transaction milestones and the alerts a go-live needs | Deeper marketing journeys, commission engines and AI scoring layered on afterwards | — |
| People | Role-based training for agents, coordinators, back office and leadership, plus documentation | Managed services, admin cover and continuous optimisation after handover | — |
The middle column is deliberate. An implementation that tries to carry every future requirement never ships; one that ignores them entirely gets rebuilt. Column two is scoped at the audit and usually starts three to six months after go-live — see Propertybase optimization and support & managed services.
"We need a Propertybase implementation" means one of three very different projects. They share a delivery model and almost nothing else — the first question on a discovery call is which one you are actually in.
No Salesforce org today, or one that has never carried real estate. The full path — platform, package, feeds, data, people — with nothing to unpick first. The cleanest of the three, and the one where architecture decisions pay off longest.
Moving off an agent CRM, a spreadsheet estate, or a transaction tool the firm has outgrown. The build is only half the job — the migration and the parallel run are what decide whether agents come with you.
Propertybase is live and not working — low adoption, listing data nobody trusts, feeds that silently stopped, automation built for a process the firm no longer follows. We diagnose before we rebuild, and starting from a blank org is rarely the cheapest route.
The boundary is the managed package. Propertybase ships in its own namespace, so its code and components are locked — you cannot edit them, and no implementation should try. What the Salesforce Platform does allow in your own org is substantial, and it is where almost all implementation work lands: custom fields on the packaged objects, validation rules, page layouts, record types, Flows, Apex triggers and Lightning Web Components built on top of Listing, Property and Inquiry. Everything inside that supported surface survives a package upgrade.
Custom development enters an implementation at three predictable places: a matching or scoring rule the Listing Browser cannot express, a commission or co-broke model with no packaged equivalent, and a bi-directional sync with a system that has no connector. We name which of your requirements fall there before the statement of work, not in week six — and everything else we try to solve declaratively first, because clicks cost less to build and far less to own. Where a build does need code, it is scoped as engineering: see Propertybase customization.
Every Propertybase implementation is assembled from these six. Their weight differs enormously by firm — a four-office brokerage with two MLS boards spends most of its budget on the first two, a replatform spends it on the third.
The foundation nobody sees and everybody depends on: where builds happen, how they get promoted, and what the production org looks like on go-live morning.
How Property, Listing and Inquiry map to your offices, teams and agents — and who can see whose records. Designed once at stage two, because it is the decision an implementation cannot walk back.
Contacts, listings, deals, documents and the activity history behind them — moved together, deduplicated, and reconciled against the source before anyone signs off. Scoped in depth on Propertybase data migration.
The feeds are the product's centre of gravity. Connecting them is a day's work; making them reconcile, dedupe and fail loudly is the part that keeps working in month nine.
The automation an org needs on day one, not the full roadmap. Routing, SLAs and milestone tasks ship with the build; marketing journeys and commission engines are scoped separately so neither delays the other.
Adoption is a deliverable, not a hope. Each role rehearses its own workflow rather than touring the platform, and the documentation stays behind so the firm is not dependent on us to troubleshoot.
Not every integration belongs in the implementation. These are the ones that do — because without them the org is not operable on go-live morning. Everything else is scoped afterwards, on its own timeline.
Listings, price changes, status and media flow MLS → Propertybase on a scheduled feed; office-originated listings flow back out. Mandatory at go-live: agents cannot work from an empty listing table.
Zillow, Realtor.com and your own website inquiries land as Inquiry records with the source stamped from the first day, so lead-source attribution starts accumulating immediately rather than from month three.
A one-way, one-time flow that carries contacts, listings, deals, documents and activity history. It runs several times against the sandbox before it runs once against production, and it is reconciled by count each pass.
Agent mail and calendar sync onto Contact and Inquiry records. Skipped at go-live, it guarantees the shadow-inbox problem the implementation was supposed to end, so it ships with the build.
Listing agreements, buyer representation and disclosures are sent from the record and write execution status back. Included when compliance sign-off is a go-live condition, deferred when it is not.
Transaction status, milestone dates and document completion sync back onto the deal record. In scope at go-live only when the firm is keeping its transaction platform rather than consolidating onto Propertybase.
Native to the same org, so a closed transaction can post commission and invoice records without an integration at all. Usually phase two — the commission model needs closed deals to test against.
Inquiry criteria and listing activity flow out to build segments; engagement flows back onto the contact. Starter nurture ships at go-live; depth is a separate build so campaign design never becomes the critical path.
The technical detail behind these — connectors, middleware, API surface and error handling — is covered on Propertybase integration and Propertybase API & integrations.
For a brokerage of 50–200 agents a full implementation typically runs 8–14 weeks; the four-office, 120+ agent build in our case study delivered in twelve. We do not quote your number before phase one, because listing volume, feed count and data quality are what move it. The client tests every phase before we advance.
Two weeks inside the business, interviewing agents, coordinators and the broker-owner, mapping every touchpoint from first inquiry to closed transaction. On the case-study engagement this surfaced fourteen distinct handoff points where data was duplicated, dropped or re-entered by hand. That gap analysis becomes the architecture blueprint — and the schedule.
Object model, sharing model and environment strategy, decided before anything is built. How offices, teams and agents are structured, what belongs on packaged objects versus custom ones, who sees whose records, and which requirements are configuration versus code. Where a previous implementation exists, we review it in full first — building on a bad foundation produces the next failure.
Package configuration, layouts and record types, routing and SLA automation, transaction milestones, and the MLS, IDX and portal feeds — all built in a sandbox and tested against real listing data before anyone sees it. Feed health-check automation is built here, not bolted on later, so a failed sync alerts the admin team instead of surfacing as a bad phone call.
Staged data loads with reconciliation counts at every pass, then a parallel run — typically two to three weeks — where both systems carry the truth and discrepancies surface before the old one is switched off. Deal and activity history moves with the contacts. There is no overnight cutover, because that is where implementations lose their agents.
Role-specific training for agents, operations and management — the case-study programme ran four weeks — followed by go-live and hypercare through the first full close cycle. Every custom workflow is documented so the firm can troubleshoot without us. Then we watch what agents actually do and fix what fights them.
Two engagements, both real estate. The first is a full implementation for a brokerage that had already been through two failed ones. 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.
Full Propertybase and Salesforce implementation — 120+ agents, four offices, twelve weeks, five phases.
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.
Back-office phase after go-live: commission reconciliation and financial reporting against the deal record.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner. We implement Propertybase; we do not resell it — so no licence revenue rides on the answer when you ask how many seats you need or whether this is the right platform at all.
We do not quote a week count before we have seen your listing volume, your MLS feeds, your office structure and the state of the data you are moving. A date promised before phase one is a date that will be met by cutting training and reporting.
Before the statement of work you know which requirements are clicks, which are code, and what the second one costs. Nobody discovers "that needs custom development" in week six, when the go-live date is already public inside the firm.
Agents judge a new system on whether their past client conversations are in it. We move deal and activity history with the contacts, reconcile by count on every pass, and run both systems in parallel until the numbers agree.
Propertybase behaves like the Salesforce Platform because it is the Salesforce Platform. Sharing models, governor limits, package upgrade behaviour and reporting all follow platform rules — and that is where most implementations go wrong.
A large share of our real estate work starts with a Propertybase org that is live and not working. We audit the architecture, the data and the actual usage, and deliver written findings on what is salvageable before anyone commits to a rebuild.
For a brokerage of 50 to 200 agents, a full implementation typically takes 8 to 14 weeks. The four-office, 120+ agent build in our case study delivered in twelve weeks across five phases. What moves that number is listing volume, how many MLS boards you feed from, how much history is being migrated and how clean it is. We do not quote your week count before phase one, because the discovery and workflow audit is what produces the schedule — and a date promised before that audit is a date that gets met by cutting training and reporting.
Six workstreams. Org, package and environment setup, so builds happen in a sandbox and get promoted safely. Data model and sharing design, mapping Property, Listing and Inquiry to your offices, teams and agents. Data migration from your current CRM with deal and activity history preserved. MLS, IDX and portal feed connection with reconciliation and health-check alerting. Go-live automation — lead routing, SLA clocks, transaction milestones and starter dashboards. And rollout: role-based training for agents, coordinators, back office and leadership, a parallel run rather than an overnight cutover, and hypercare through the first close cycle.
Six things. A Salesforce org with admin access and a sandbox. Active MLS membership with API or feed access for every board you list on. An internal operations owner with the authority to sign off workflow decisions — this is the single biggest predictor of whether a project runs to schedule. A list of your known lead sources, so nothing is capturing into a system we did not connect. Your state or jurisdiction compliance checklist for transactions. And the availability to run two to three weeks in parallel during cutover. Everything else we can discover; those six you have to bring.
Four things, in roughly this order of impact. Data — how many source systems, how much history, and how clean it is; a migration is a project, not an import. Feeds — one MLS board is straightforward, four boards with different field conventions is not. Structure — the number of offices, teams and sharing boundaries the model has to express. And custom development, which enters at three predictable places: a matching or scoring rule the Listing Browser cannot express, a commission or co-broke model with no packaged equivalent, and a bi-directional sync with a system that has no connector. Licences are a separate cost entirely and come from the vendors, not from us.
Yes, and it is a large share of our real estate work. The brokerage in our case study had already been through two failed CRM implementations, both delivered by generalist partners with no real estate workflow depth, and we reviewed both in full before designing anything — building on a bad foundation produces the third failure. We audit the architecture, the data and the actual usage, then deliver written findings on what is salvageable and what needs a clean rebuild before you commit to either. Starting from a blank org is rarely necessary and almost never the cheapest route.
Not if the migration is scoped as a migration. Contacts, listings, deals, documents and the activity history behind them move together, deduplicated on load and reconciled by count against the source on every pass. This matters more than any other technical decision in the project, because agents judge a new system entirely on whether the record of their past client conversations is in it. Implementations that migrate current records and leave history behind lose adoption in week one and never recover it — which is why we run staged loads against a sandbox first and a parallel run before the old system is switched off.
Propertybase Salesforce Edition runs inside a Salesforce org, so Salesforce platform licensing is always part of the total cost — it is not an alternative to Salesforce, it is an application on it. How those licences are provisioned and priced varies by agreement, and Lone Wolf sells the Propertybase side, so get both numbers in writing from the vendors before you budget. Twopir does not resell either licence, which is also why we have no incentive to tell you that you need more seats than you do.
Bring us a first Propertybase build, a replatform off a CRM you have outgrown, or an implementation that already stalled once. We will tell you which of the three you are in, what it takes, and what decides the schedule — before anyone writes a proposal.
Salesforce architecture, Propertybase delivery & real estate operations
