You bought Salesforce for one system of record. Why does your WhatsApp live somewhere else?

Your real estate firm bought Salesforce to be the one place every deal lives: the portal lead, the listing, the pipeline stage, the closed-won. Look at where the conversation itself happens. A Bayut or Property Finder lead lands in Salesforce as a Lead record, and the call that qualifies it, the WhatsApp thread that keeps the buyer warm for six weeks, and the voice note that locks in a viewing all happen somewhere else: on the agent’s personal phone, or inside a vendor tool that keeps its own copy of the chat. Salesforce ends up holding the paperwork of the deal. The relationship that produced it lives outside the org.

That gap is not a feature gap, it is architecture. A bolted-on communication tool does not extend Salesforce, it stands up a second system of record next to it. In a WhatsApp-first market, that second system is where the business happens, and the firm that paid for one system of record ends up running two. The question worth asking before signing another vendor contract is the one agents already answer with their behavior every day: who actually owns that customer, you or the agent?

What does native Salesforce CTI mean for a real estate firm?

Native means the call, the WhatsApp voice call, and the WhatsApp chat message are written as Salesforce records the moment they happen, tied to the Lead or Contact, not synced in afterward from a vendor’s own database. A call becomes a Call__c record in real time, with the recording, transcript, and sentiment score landing on Recording__c, Transcript__c, and Sentiment__c the moment the call ends. Routing runs on Salesforce’s own Omni-Channel, so a fresh portal lead from Bayut, Property Finder, PropertyGuru, or Property24 reaches the listing owner without opening a second console.

Automation runs in Flow directly against that record: reassign a stalled lead after a set window with no callback logged, fire a follow-up task the moment a call ends without a next step recorded, flag a lead that has gone quiet for three days. None of that waits on a sync job or a webhook from an outside app, because the record it fires against was born in Salesforce, not copied there afterward. Access to the call, the recording, and the transcript follows the Salesforce permission model an admin already manages: the same profiles, roles, and sharing rules that govern every other object in the org, so a regional sales manager sees their region’s calls and nobody else’s, without a second login to a separate portal.

Why does a bolt-on WhatsApp tool create a second system of record?

Because the tool keeps its own copy of the conversation in its own cloud, so the Lead record in Salesforce and the conversation that moves the deal sit in two different places someone has to reconcile by hand. The portal lead auto-routes into Salesforce cleanly enough. The chat that follows it, the one where the buyer asks about the payment plan or the handover date, lives in a separate app the sales manager cannot see from the record.

That split is the pattern behind agents on their personal WhatsApp and leads that leave with them: an agent copies a client’s number into a personal WhatsApp account to keep the conversation moving, and when that agent leaves the firm, the number, the chat history, and the relationship walk out with them. It shows up as three familiar symptoms: the pipeline stage in Salesforce does not reflect what was said on the call, a departing agent’s WhatsApp history goes with their phone, and nobody can answer “what did we tell this buyer” without asking the agent directly. WorkDial writes the call and the WhatsApp thread to the same record the portal lead landed on, instead of syncing a copy in later; the full architecture argument for why that distinction matters lives on the Salesforce CTI architecture page.

What does native require, in Salesforce terms?

Native requires four specific things, not a marketing label: the call record is a native Salesforce object born in real time, routing runs on Omni-Channel, automation runs in Flow, and access runs on Salesforce’s permission model. Applied to WhatsApp, the same structure holds: the agent opens a number-masked WhatsApp chat directly from the record, never seeing or owning the client’s number, and can place a recorded WhatsApp voice call from that same record, logged automatically the moment the call ends.

WorkDial was first to market with WhatsApp voice calling inside Salesforce. That single behavior, a voice call placed and recorded from the record itself rather than dialed from a separate app, is the test a real estate firm can run in a demo: open a Lead, place the WhatsApp call, and watch the recording and transcript land on the record before the call has even ended. For the full walkthrough of what separates that from a synced-in copy, see native versus integrated CTI in Salesforce.

Where does the recording live?

Telephony has to run on a carrier, so the honest answer is that the audio can sit in the customer’s own Twilio account, not inside Salesforce itself. WorkDial runs on bring-your-own-account (BYOA) Twilio, billed at carrier cost with no markup, and WorkDial keeps no copy of the recording on its own infrastructure. A firm can also route the recording to native Salesforce Files in its own org, an option no rival offers, or to its own cloud storage.

That means the call record, the transcript, and the sentiment score are native Salesforce data, while the audio file sits in infrastructure the customer owns and chooses. No vendor should promise an unconditional “your data never leaves Salesforce,” because the transport has to go somewhere, and BYOA Twilio is a supported configuration precisely because some firms want their own carrier account. The defensible version is narrower and checkable: the record is native, the recording’s destination is the customer’s choice, and no copy sits with WorkDial.

None of this is a compliance claim. No tool makes a real estate firm compliant with a given regulation on its own, and buying WorkDial does not change that obligation. What native architecture provides is the evidentiary trail: a recorded, consented call, tied to the record, that a firm’s own compliance program can reproduce and point to when a regulator or a buyer asks what was said and when.

How do WorkDial and ValueText fit together on this?

WorkDial is the voice layer, covering calls and WhatsApp voice calls, and ValueText is the messaging layer, covering WhatsApp chat and SMS, together forming one Salesforce-native communication stack against the same record. A real estate firm running both gets the call, the chat thread, and the voice note on the same Lead, with nothing stitched together by a middle layer: a buyer’s payment-plan question sent by WhatsApp chat and the follow-up call that answers it both post to the record the portal lead created.

WorkDial is built by the team behind ValueText, the Salesforce-native messaging platform with 4.97 stars across 100+ AppExchange reviews. Buying both together drops the combined total by 20%, detailed on the bundle page.

The fix is architectural, not a new app

A real estate firm does not need another tool bolted onto Salesforce, it needs the conversation that happens on WhatsApp and the phone written to the same record the portal lead landed on. That is what changes when routing, the call, the chat, and the recording all run inside the org instead of syncing in from somewhere else: the deal history stays with the business when an agent leaves, and a manager can read the conversation without opening a second tool. The conversation is a company asset. It should live where the business lives, inside Salesforce, not on a phone that quits.

Start a trial and watch a WhatsApp call write itself to a Lead record in your own org, or bring your current stack to a call with sales.

Start your trial or Talk to sales.

Written by WorkDial, The voice layer of Salesforce. WorkDial is built by the team behind ValueText, the Salesforce-native messaging platform, rated 4.97 stars across 116 AppExchange reviews.