Propertybase ships in its own locked namespace, and everything you add lives in yours: custom fields on Listing, Property and Inquiry, validation rules, record types, Flows, Apex triggers, custom objects and Lightning Web Components. Twopir Consulting designs that layer so it does what the brokerage needs and still survives every package upgrade. Extend the product. Never fight it.
Trusted by 500+ organizations — including brokerages, property managers and real estate investment groups whose commission models, agent workspaces and compliance workflows Twopir Consulting builds on top of the packaged objects.
What We Build
Customization is not the risk. Undisciplined customization is — and the bill arrives at the next package upgrade, or the next time somebody needs a report the model cannot express. Every custom object is a permanent liability as well as a feature.
A custom Property object built beside the packaged one, because it was faster than learning the existing model. Now the MLS feed populates one and the reports read the other, and no amount of automation reconciles a data model that disagrees with itself.
Apex that depends on a packaged field's behaviour, or a component that assumed how the Listing Browser returns results. It works until the vendor ships a release, and then it is broken in production with no supported path back.
A trigger written for a field update, because the person available was a developer rather than an admin. Now a picklist change is a deployment with tests, your team cannot maintain it, and the cost of every future adjustment went up permanently.
Two hundred custom fields on Listing, forty of them populated, nobody able to say which. Page layouts get longer every year, agents scroll past what matters, and data quality quietly degrades because half the fields have no defined meaning.
There is no sandbox on the upgrade path, so a vendor release is discovered in production. The firm starts deferring upgrades, falls behind supported versions, and gradually loses access to the fixes and features it is paying for.
A screen that impressed leadership in a review and adds four clicks to the thing an agent does forty times a day. Adoption drops, the data stops being true, and the customization gets blamed for a problem its brief created.
Propertybase customization means everything you build in your own Salesforce org on top of a managed package you cannot edit. The package ships in its own namespace: its objects, its Apex, its Lightning components, its Listing Browser and its MLS and portal synchronisation engine are the vendor's, and they are locked. What the Salesforce Platform allows in your namespace is substantial, and it is where every well-built Propertybase customization lives — custom fields on the packaged objects, validation rules, page layouts, record types, Flows, Apex triggers and classes, custom objects of your own, and Lightning Web Components. Vendor documentation on the product's own configuration surface is at help.propertybase.com.
The single most valuable property of that arrangement is upgrade safety. Because your work sits in your namespace rather than inside the package, a vendor release lands without a rebuild — provided nothing you built depends on the vendor's internals. That proviso is the whole discipline: build on the packaged objects, never against assumptions about how the packaged code behaves, and keep a sandbox on the upgrade path so a release is a test run rather than an incident.
Who this is for: CRM managers, operations leaders and technology leads at firms whose Propertybase org almost does what they need. 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 — and the honest first question is always whether a requirement needs building at all.
What is locked, what is configuration, and what is genuinely custom development
| Locked in the package | Configuration in your org | Custom development | |
|---|---|---|---|
| Data model | The packaged Listing, Property and Inquiry objects and their own fields | Custom fields, record types, page layouts, validation rules and lookups on those objects | New custom objects for models the package has no equivalent of, and their relationships |
| Logic | Vendor Apex, the Listing Browser and the matching implementation behind it | Flows on the packaged objects — assignment, field updates, stage gates, alerts | Apex triggers and classes where declarative tooling cannot express the rule safely |
| Interface | The vendor's own Lightning components and their internal behaviour | Layouts, list views, compact layouts, Lightning app and record page composition | Lightning Web Components for agent and coordinator workspaces |
| Who maintains it | Lone Wolf, on their release schedule | Your admin, without a deployment | A developer, with tests and a deployment path, for as long as it exists |
The middle column is far wider than most firms assume, and it is where we try to land every requirement first. Custom development 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; the last of those is covered on Propertybase API & integrations.
Three tiers with three very different price tags and three very different maintenance costs. Almost every requirement that arrives asking for the third turns out to belong in the first.
No code at all. Fields, layouts, record types, validation and Flow — the surface your own admin can change afterwards without a deployment, which is exactly why we exhaust it first.
Code that sits on the packaged objects rather than beside them. Apex and Lightning Web Components that make the product do something it does not do, without forking anything or breaking an upgrade.
New custom objects and the applications around them, for models the package has no equivalent of. The most expensive tier to own, and the one we scope with the maintenance cost stated up front.
Build on the packaged objects, never beside them. A custom Property object next to the packaged one is the most expensive mistake available in this platform, because the MLS feed will populate the vendor's and your reports will read yours. Never depend on the vendor's internals. Use the packaged objects and their documented fields; do not write code that assumes how packaged Apex or the Listing Browser behaves, because that assumption has a release date attached to it.
Prefer the tier your admin can maintain. Every requirement solved in Flow rather than Apex is one your team can change next quarter without us — a trigger written for a field update raises the cost of every future adjustment permanently. Keep a sandbox on the upgrade path. Run the customization test set against each package release before production takes it. Firms without that habit start deferring upgrades, and then fall behind the supported versions they are paying for.
These are the six requirements that recur across brokerages and genuinely cannot be met by the package as delivered. Anything not on this list, we will try to configure before we quote to build.
The most common genuine custom build in this platform. Every brokerage's split structure is different enough that no packaged model fits, and it has to be right to the cent or agents stop trusting it.
The Listing Browser matches inquiry criteria against inventory well. Where a firm's matching logic is a competitive advantage — investment criteria, yield thresholds, portfolio fit — it needs building.
Lightning Web Components that collapse a multi-record task into one screen. The measure is clicks removed from something done forty times a day, not how the screen looks in a review.
Requirements vary by jurisdiction, transaction type and franchise agreement, and the audit trail has to assemble itself. This is where a customised org earns its keep in a regulatory review.
Where a firm's business is not only sales. Tenancies, renewals, maintenance and rent rolls have no packaged equivalent, and bending Listing to carry them is the mistake that has to be undone later.
Often the first engagement rather than the last. Orgs arrive carrying years of accumulated fields, triggers and objects, and the fastest route to a new capability is usually removing what is in the way.
Every customization has a relationship with something outside itself — a feed that populates it, a report that reads it, or a package release that could break it. These are the eight to check before building anything.
A custom field the feed does not populate is a field agents will leave empty. Anything meant to be authoritative has to be mapped into the sync, or explicitly designated as manually maintained with an owner.
The relationship that decides whether customization ages well. A sandbox on the upgrade path with a runnable test set turns a vendor release from an incident into a scheduled half-day.
Relationships decided at build time determine what can ever be reported. A lookup where a master-detail belonged means no roll-up summaries, and that is discovered when leadership asks for a number.
A new object inherits none of the visibility rules the packaged ones carry. Office and team boundaries have to be re-expressed on it deliberately, or a commission record becomes visible to the wrong agent.
A trigger and a Flow on the same object both fire, in an order most teams have never documented. Every code addition needs to be reconciled against the declarative layer already there, or the two will undo each other.
A custom commission model exists to produce something the ledger can consume. Designing it without the accounting integration in view produces a calculation nobody can post, which is where most of these builds stall.
Anything reaching outside the org inherits Salesforce's callout and limit behaviour, so the pattern matters more than the code. The engineering detail is on our API and integrations page.
Agentforce and Einstein read what is on the record. Fields that are unpopulated or ambiguously defined make AI output confidently wrong, which is a customization problem rather than a model problem.
The automation layer that sits alongside this is Propertybase automation; the API-level detail behind anything reaching outside the org is Propertybase API & integrations.
Stage two exists to talk you out of half of it. Every requirement that survives into a build has a written reason why configuration could not meet it, and a stated cost of ownership.
What the firm needs, and what the org already contains. This includes the inventory nobody has: every custom field, object, trigger and component, what populates it and whether anything still reads it. A surprising number of requirements turn out to be already built, once, badly.
Each requirement assigned to configuration, extension or new build, with a written reason and a maintenance cost. This is the stage that saves money — most requirements arriving as "we need custom development" are met by fields, record types and a Flow, and we would rather say so before the statement of work.
Data model, relationships and sharing decided before anything is built — including how new objects roll up for reporting, because a lookup where a master-detail belonged cannot be changed once there is data. Nothing is designed against vendor internals, and every extension point is a documented one.
Configuration first, code where the tier assignment said code, with test coverage that exercises the failure paths rather than the happy one. Built in a sandbox, deployed through a defined path, and reviewed against the agent workflow it is meant to shorten rather than against a demo script.
A sandbox left on the package upgrade path, a runnable test set, and documentation of every customization and why it exists. The measure of a finished engagement is that the next vendor release is a scheduled half-day for your admin rather than a call to us.
Two engagements, both real estate. The second is the clearest example of custom development earning its cost — a commission model with no packaged equivalent, built on the closed deal record. The numbers are the ones those clients measured.
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.
Stage-gated compliance workflow and role-based workspaces built on the packaged transaction records.
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.
Custom commission and disbursement model built against the closed deal record and posted to the ledger.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner. Custom development is the most profitable thing a consultancy can sell and the most expensive thing a client can own, which is why our scoping stage is designed to reduce it.
Every requirement is labelled configuration, extension or new build, with a written reason and a maintenance cost. Most things arriving as "that needs custom development" are met by fields, record types and a Flow — and you should hear that before the statement of work, not after.
A custom Property object next to the packaged one is the most expensive mistake available here: the MLS feed populates the vendor's and your reports read yours. We extend the model the product ships rather than quietly forking it.
Relationships decided at build time determine what can ever be reported on. A lookup where a master-detail belonged means no roll-up summaries — and that is discovered months later, when leadership asks for a number the model cannot produce.
Customization ages badly without a test set that runs against each package release. Firms without that habit start deferring upgrades and fall behind the supported versions they are already paying for.
A component that impresses in a review and adds four clicks to something an agent does forty times a day has made the org worse. Adoption is the acceptance criterion for interface work, not the demo.
Far more than most buyers expect, with one hard edge. Propertybase ships as a managed package in its own namespace, so its objects, its Apex, its Lightning components, its Listing Browser and its MLS and portal engine are locked — you cannot edit them. Everything you add lives in your own namespace and is effectively unbounded: custom fields on Listing, Property and Inquiry, validation rules, record types, page layouts, Flows, Apex triggers and classes, entirely new custom objects, and Lightning Web Components. In practice that means you can change almost any behaviour by building on top of the packaged model; what you cannot do is change the model itself.
Who maintains it, and what a change costs. Configuration — custom fields, validation rules, record types, page layouts, Flows — can be changed by a trained Salesforce admin without a deployment, which means your team owns it. Custom development is Apex, Lightning Web Components and new custom objects: every change is a deployment with tests, and it requires a developer for as long as it exists. Both survive a package upgrade, so upgrade safety is not the distinguishing factor. Cost of ownership is. That is why we assign each requirement a tier in writing before quoting, and why most requirements that arrive labelled "custom development" leave as configuration.
Not if it was built in the supported way. Because your work lives in your own namespace rather than inside the package, custom fields, Flows, Apex and components on top of the packaged objects survive a vendor release. What breaks is code that depended on the vendor's internals — assumptions about how packaged Apex behaves, or how the Listing Browser returns results — and anything that assumed an unprefixed API name for a packaged field. The discipline that makes upgrades boring is a sandbox kept on the upgrade path with a runnable test set, so a release is a scheduled half-day rather than an incident. Firms without that habit start deferring upgrades and fall behind supported versions.
Yes, and it is the most common genuine custom build on this platform. Every brokerage's split structure differs enough — tiers, caps, rolling thresholds, co-broke shares, referral fees, partner-firm arrangements — that no packaged model fits, so it is built as custom objects with calculation triggered on transaction close. Two design points matter more than the maths. It has to be auditable line by line, because agents will question a statement and the answer has to be visible on the record. And it has to be designed with the accounting integration in view from the start, since a calculation the ledger cannot consume is where most of these builds stall. One firm we worked with moved from three days of month-end reconciliation to same-day statements on that basis.
Extend the packaged ones whenever the concept already exists in the model. Building a custom Property object beside the packaged one is the single most expensive mistake available in this platform: the MLS feed will populate the vendor's object and your reports will read yours, and no amount of automation reconciles a data model that disagrees with itself. New custom objects are correct when the concept genuinely has no packaged equivalent — commission plans, co-broke arrangements, tenancies and leases, portfolio structures. When you do build one, decide the relationships before the first record exists, because a lookup where a master-detail belonged cannot be changed later and it is what determines whether you can report on it at all.
With an inventory, not a new requirement. We catalogue every custom field, object, trigger and component, then measure what is actually populated and what is actually read — orgs routinely carry two hundred custom fields on Listing with forty in use, and triggers nobody has been able to explain for years. From there you get a retirement plan for what is duplicated or dead, a refactoring list for code that should have been configuration, and a sandbox on the upgrade path with a test set that runs. It is unglamorous and it is almost always the fastest route to the capability you originally called about, because most new requirements are blocked by something already in the way.
Everything in the configuration tier, yes — that is precisely why we exhaust it first. Fields, record types, layouts, validation rules and Flows can all be changed by a trained Salesforce admin without a deployment. Custom code is different by nature: Apex and Lightning Web Components require a developer and a deployment with tests for every change, which is a permanent increase in the cost of adjusting that part of the org. We document every customization and why it exists, hand over runbooks, and where a firm has no admin of its own that gap is worth solving explicitly rather than by default — see our support and managed services page.
A commission model no product fits, a screen your agents fight, an org carrying years of customization nobody can explain, or a build you would like a second opinion on. We will tell you which tier it belongs in — and what it will cost you to keep.
Salesforce architecture, Propertybase delivery & real estate operations
