Routing, SLA clocks, nurture sequences, milestone tasks and compliance gates — built in Salesforce Flow against Propertybase's own objects, not bolted on beside them. Twopir Consulting designs the automation layer, migrates what is still running on retiring tooling, and monitors it after go-live. Every inquiry gets an owner, a clock and a next action.
Trusted by 500+ organizations — including brokerages, property managers and real estate investment groups whose routing, follow-up and transaction workflow Twopir Consulting designs, migrates and monitors.
What We Automate
Most Propertybase orgs we audit are not short of automation. They are carrying years of it, built by different people for a process the firm no longer follows. Automation nobody can explain is automation nobody will fix.
Assignment is the easy half. Without an SLA clock and an escalation path behind it, a lead assigned to an agent who is showing a property all afternoon is indistinguishable from a lead nobody was given — and both convert the same way.
Some rules are in Flow, some in Process Builder, some in an Apex trigger somebody wrote in 2019. They fire in an order nobody has documented, occasionally undo each other, and every new requirement gets added to whichever layer the last person understood.
The process is active, the template exists, and nothing arrives — because the automated-email scheduler was never restarted after the change, or because the sequence was built against a field the feed stopped populating. Nobody notices until a buyer says they never heard back.
A Flow errors on a record that hit a validation rule and stops. The user sees nothing useful, the admin sees nothing at all, and the automation silently skips a subset of records every day — usually the unusual ones, which are the ones that mattered.
Deadline alerts are driven off fields the coordinator has to update by hand. When the date moves and the field does not, the reminder arrives after the contingency expired — which is worse than no reminder, because the team stopped watching for it.
Every rule its author thought was important sends an alert. Twenty a day become background noise, the one that mattered is missed, and the fix that gets proposed is always another notification rather than fewer, better ones.
Propertybase automation is Salesforce automation applied to real estate objects. Because Propertybase installs as a managed package into your own org, Property, Listing, Inquiry and the transaction records behave like any other Salesforce object: Flow can create, update, route and escalate them, Apex can act on them where declarative tooling cannot, and the product ships its own layer on top — email automation driven from its Template object, drip campaigns, recurring birthday and anniversary sends, and mass campaigns. Vendor documentation for those sits at help.propertybase.com.
Two platform facts shape every automation engagement. First, Salesforce has been retiring the older declarative tooling — Workflow Rules and Process Builder — in favour of Flow, so an org still carrying rules on those surfaces has migration work ahead of it whether or not it has an automation requirement. Second, Propertybase's own email automation has operational steps of its own: sequences are activated per account, and the automated-email scheduler has to be restarted from the Control Center for changes to take effect. Firms that do not know that second detail spend weeks debugging automation that was correct all along.
Who this is for: operations leaders, CRM managers and admins running a live Propertybase org where routing, follow-up or transaction workflow is either missing, untrusted, or spread across tooling that is going away. 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.
The four surfaces a Propertybase automation requirement can land on, and how to choose between them
| Salesforce Flow | Propertybase email automation | Apex | Marketing platform | |
|---|---|---|---|---|
| Best for | Record-driven logic: routing, assignment, field updates, task creation, stage gates, escalation | Transactional and lifecycle email sent from the record — welcome, listing alerts, birthdays, drips | Logic too complex, too stateful or too high-volume for declarative tooling to express safely | Multi-step campaigns with segmentation, behavioural scoring and cross-channel journeys |
| Who maintains it | Your admin, with training — this is the point of building here first | Your marketing or operations owner, inside the product's own configuration | A developer. Every change is a deployment with tests | Your marketing team, in a tool built for them |
| Watch out for | Order of execution when several Flows touch one record; errors that fail silently | Activation per account, and restarting the email scheduler after a change | Governor limits at volume, and the cost of owning code nobody else can read | Sync latency and segment membership drifting from the CRM's own criteria |
| Our default | First choice for anything record-driven | First choice for email that belongs to the record rather than to a campaign | Last resort, and scoped as engineering when it is genuinely needed | Where campaign depth is the requirement, not where a single email is |
Most requirements land in the first two columns. When one genuinely needs the third, it is scoped as engineering — see Propertybase customization — and when campaign depth is the real requirement, the marketing platform is the honest answer rather than a Flow pretending to be one.
Firms arrive here for one of three reasons: they have no automation, they have automation on tooling that is going away, or they have so much of it that nobody dares change any.
The automation an org needs and does not have: routing with a clock behind it, nurture that runs without an agent remembering, milestone tasks that generate themselves, and escalation that reaches a person.
Moving automation off Workflow Rules and Process Builder onto Flow — not rule by rule, but by re-deriving what the org is actually supposed to do and consolidating the accumulated exceptions on the way.
Making the automation layer observable and safe to change. This is what turns a fragile org into one where a new requirement takes an afternoon instead of a risk assessment.
Almost everything a brokerage wants automated is declarative. Flow can act on the packaged Listing, Property and Inquiry objects the same way it acts on any Salesforce object — assigning an inquiry by territory, setting listing-agent fields from the listing owner, advancing a stage when a document is executed, generating a task set when a milestone date lands. All of it lives in your namespace rather than the managed package's, so all of it survives a package upgrade.
Code becomes the right answer at three predictable points: matching or scoring logic the Listing Browser and Flow cannot express, a transformation too stateful to run safely at volume inside declarative tooling, and anything that has to reach outside the org synchronously. Those are engineering, and we scope them as engineering. Everything else we solve with clicks — because clicks cost less to build and far less to own, and because your admin can change them without us.
Ordered by how quickly a brokerage feels them. Response time first, because it is the one that converts; back-office automation last, because it cannot be right until the deal record is.
Every inquiry gets an owner within seconds and a clock it cannot outrun. Assignment without an escalation path is the most common half-built automation we find.
Not every inquiry deserves the same response. Weighted scoring separates the buyer who has viewed four listings this week from the one who downloaded a guide.
Buyers who are not ready this quarter are next year's closings. Built on Propertybase's own email automation where the message belongs to the record, and on the marketing platform where it belongs to a campaign.
The listing record maintains itself. Status transitions, price-change history, expiry warnings and agent-field population happen because the data changed, not because somebody remembered.
From accepted offer to closing, the milestones, documents and deadlines drive themselves — and the audit trail assembles as a by-product rather than as a project before every review.
Splits calculate from the closed deal record and statements generate without re-entry. The automation that most visibly rebuilds agent trust, and the one that most depends on everything above being right.
Every rule below depends on a system outside the automation layer being current. This is why an automation engagement almost always begins by checking the feeds — a routing rule reading a stale status is worse than no rule at all.
Price changes, status transitions and new inventory arriving on the feed are what fire listing alerts and new-match notifications. A stale feed produces confidently wrong automation, which agents notice before leadership does.
Portal and website inquiries are the highest-value routing trigger there is, because the SLA clock starts the moment they land. Source attribution has to be stamped on capture or the escalation rules cannot differentiate by channel.
Automation that measures response time needs to see the response. Without agent mail and calendar syncing onto the record, an SLA clock records a breach every time somebody replies from their phone.
Execution status written back onto the record is what lets a stage gate open by itself. Without it, the compliance workflow is a checklist somebody ticks — which is the manual process the automation was meant to remove.
Deadline alerts are only as good as the dates behind them. Syncing milestone dates from the transaction platform is what stops a contingency reminder arriving after the contingency expired.
Where campaign depth is the requirement, the journey belongs in the marketing platform and the trigger belongs in the CRM. Engagement flows back onto the contact so scoring rules can read it.
Commission automation fires on transaction close and posts into the ledger. Native to the same org where the accounting application allows it; a monitored bi-directional sync where it does not.
Scoring and drafted follow-up read the same records deterministic automation writes. Worth adding once the rules layer is trustworthy — an AI grounded in stale data is a faster way to be wrong.
Getting those feeds right is its own engagement — see Propertybase integration — and the AI layer on top is Propertybase AI & Agentforce.
Nobody can safely add automation to an org whose existing automation is undocumented. Stage one is an inventory, and it is usually the stage that changes the scope.
Every Flow, Workflow Rule, Process Builder process, Apex trigger, email process and scheduled job in the org — what fires it, what it does, and whether anything still depends on it. Orgs are routinely running rules nobody has been able to explain for years, and those are what make the next change dangerous.
What should happen, decided with the people who do it today. Routing rules that reflect how the firm really allocates leads, SLA windows the brokerage will actually hold itself to, and an escalation path with a named owner. Design here, not in the builder — automation designed while configuring inherits every quirk of the tool.
Flow first, the product's own email automation for record-driven sends, code only where the first two genuinely cannot reach. One Flow per object and event, in a documented order, with fault paths on every branch — the error handling is built here, not after the first silent failure.
Existing behaviour captured as tests before anything is replaced, then run in parallel so the new layer proves itself against real records before the old rules are deactivated. Where the product's email automation is involved, that includes verifying the scheduler after activation rather than assuming a sequence is sending.
Failure alerting to a named owner, documented order of execution, and a notification audit after four weeks — because the first version always sends too many alerts. Then we watch what agents actually do and adjust the rules that fight them rather than adding more.
Two engagements, both real estate. The first replaced manual lead triage with Flow-based routing across four offices; the second automated commission against 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.
Manual lead triage replaced with three-tier Flow routing, a ten-step drip sequence and behavioural escalation.
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.
Commission calculation and disbursement automated from the transaction close event.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner. Most automation engagements we take on end with fewer rules than they started with — consolidated, documented, and finally possible to change without a risk assessment.
Adding a Flow to an org whose existing rules are undocumented is how two automations end up quietly undoing each other. Stage one is a full inventory of what fires, in what order, and whether anything still depends on it.
The default failure mode of declarative automation is silence: a record hits a validation rule, the Flow stops, and nobody is told. We build the error handling and the alerting at the same time as the happy path, because retrofitting it never gets prioritised.
Propertybase email automation has operational steps that are not obvious — activation per account, and restarting the automated-email scheduler after a change. Firms without that knowledge spend weeks debugging sequences that were configured correctly all along.
A routing rule reading a stale listing status is worse than no rule, because it is confidently wrong at speed. Automation engagements here almost always begin by verifying that the data the rules depend on is actually current.
Declarative first is not a stylistic preference. It is what decides whether your team can change a routing rule next quarter or has to raise a ticket with us — and we would rather be called for the architecture than for the picklist.
Anything that is record-driven, plus the product's own email layer. Because Propertybase installs as a managed package into your Salesforce org, Property, Listing and Inquiry behave like any Salesforce object, so Flow can route and assign inquiries by territory, property type and agent capacity, run SLA clocks and escalation, set listing-agent fields from the listing owner, advance transaction stages when a document is executed, generate milestone task sets, and fire deadline alerts. On top of that Propertybase ships email automation driven from its Template object, drip campaigns, recurring birthday and anniversary sends, and mass campaigns. Where campaign depth is the requirement rather than a single record-driven email, that work belongs in Marketing Cloud or Account Engagement instead.
Yes, eventually — Salesforce has been retiring both in favour of Flow, so an org still carrying rules on those surfaces has migration work ahead of it regardless of whether it has a new automation requirement. The mistake is migrating rule by rule. Years of accumulated exceptions get carried forward, including the ones that contradict each other. We inventory everything first, capture the current behaviour as tests, then re-derive what the org is actually supposed to do and consolidate into one Flow per object and event with a documented order of execution. Most migrations we run finish with materially fewer rules than they started with, and check the current retirement timeline with Salesforce directly before you plan around a date.
On the four-office, 120+ agent build in our case study, Flow-based routing assigns a lead within 90 seconds of entry using a three-tier priority model based on geography, property type and agent capacity, and no lead waits more than 15 minutes for a first touch regardless of the hour — down from an average first contact time of four to six hours under manual triage. Those numbers are that engagement's, measured as stated. What decides yours is not the technology but the escalation rule: assignment alone does not produce a response, so the clock and the named person it escalates to matter more than the routing logic.
The most common cause is operational rather than logical. Propertybase email automation has to be activated for the account, and the automated-email scheduler has to be restarted from the Control Center — under Propertybase Services, Automated Emails — for changes to take effect. Sequences that look correct in the builder will sit there indefinitely if that step was missed. The second most common cause is a sequence built against a field the MLS feed stopped populating, so the entry criteria never match. Both are quick to diagnose and are exactly the kind of thing an org running without an owner will not notice until a buyer says they never heard back.
Yes, when it is built in the supported way. Propertybase ships in its own namespace and its code and components are locked, but Flows, custom fields, validation rules and Apex you build on top of the packaged objects live in your namespace and survive an upgrade. What does need testing at each release is anything reading a packaged field the vendor may change, so we keep a sandbox on the upgrade path and run the automation test set there before production takes a new version. That is a small recurring cost and it is far cheaper than discovering a broken routing rule on a Monday morning.
Only if somebody built the fault handling, and in most orgs nobody did. The default behaviour of declarative automation is to fail quietly: a record hits a validation rule or a lookup returns nothing, the Flow stops, and the automation silently skips a subset of records every day — usually the unusual ones, which are the ones that mattered. We build fault paths on every branch, route failures to an error queue with retry rather than discarding them, and alert a named owner instead of writing to a log nobody reads. The measure of a finished engagement is that your admin knows within minutes and can diagnose it from a runbook.
That is the point of building declaratively wherever it is possible. Flow, the product's own email automation and configuration-driven rules can all be changed by a trained Salesforce admin without a deployment, and we document the order of execution per object so a change is safe to make. Custom code is different: every change to Apex is a deployment with tests, which is one of the reasons we scope it last rather than first. We hand over runbooks and documentation at close of project, and where a firm has no admin of its own that gap is worth solving explicitly — see our support and managed services page.
An org carrying three generations of automation, a routing model that never produced a response, email sequences that are active and silent, or no automation at all. We will tell you what to remove before we tell you what to add.
Salesforce architecture, Propertybase delivery & real estate operations
