The Salesforce integration has been generally available in Orbit's integration marketplace for a while, and we have not done a good job of explaining the model behind it. This post fixes that. It covers why Salesforce cannot natively show your SMS, WhatsApp, and email history, how the Orbit integration bridges that gap by writing message events into Salesforce activities, the exact wiring steps, and a Salesforce Flow pattern for handling inbound replies. If you are deciding how a CRM and a customer data platform split the work, the CDP vs CRM breakdown is the companion read.
Why Salesforce can't show message history natively
Salesforce is excellent at recording what a sales or support process did: leads, opportunities, cases, tasks, owners. What it does not have is a listener on your messaging channels. An SMS delivered to a customer, a WhatsApp conversation handled by an agent, an email sent from a campaign — none of that touches Salesforce unless something pushes it in. The Salesforce data model has no object for "message sent on a channel," only generic activities (tasks and events) that a rep logs by hand or an external system writes into.
That gap shows up as soon as messaging joins phone calls in your contact center. A rep opens a contact and sees every call logged, every email captured by Einstein Activity Capture or your email integration — and nothing about the SMS that closed the deal or the WhatsApp thread where the customer confirmed the appointment. The interaction happened; Salesforce just has nowhere to put it by default. With privacy, the same gap is worse: your tenant-owned messaging data only enters Salesforce through an integration you authorized, so nothing appears until you wire it.
The contact–activity junction
The integration's model is a junction between two records. On one side, the Salesforce Contact, Lead, or Account the message belongs to. On the other, an Activity — the object Salesforce already renders on the record timeline, reports on, and triggers automations from. Orbit occupies the middle: contacts, accounts, leads, and opportunities sync from Salesforce into Orbit so agents get CRM context inside the inbox, and outbound message events sync from Orbit back into Salesforce as activities on the matched record.
The match is by the phone number or email address on the synced contact, so an outbound SMS resolves to the same Salesforce person whose record the agent had open. Because the events land as activities rather than custom objects, they inherit everything Salesforce already does with activities: timeline display, task reports, related lists, and Flow triggers. The unidirectional parts are explicit — CRM records flow into Orbit for agent context, message events flow back to Salesforce for the activity log — and both directions are tenant-owned controls: the scopes you grant, the sync you enable, and the data that moves stay inside your own connected org and account.
Step-by-step wiring
- Open the marketplace. In Orbit, go to Settings → Integrations and find Salesforce.
- Connect your org. Click Connect, sign in to Salesforce, and grant the OAuth scopes. A Salesforce admin typically approves the connected app the first time.
- Confirm the sync. Contacts, accounts, leads, and opportunities start flowing into Orbit. The card flips to Connected once the first sync completes.
- Verify the write-back. Send a test SMS, WhatsApp, or email from Orbit to one of the synced contacts and confirm an activity appears on that record's timeline in Salesforce.
From that point on, reps see every channel touch alongside their calls, and agents working in the Orbit inbox see the caller's Salesforce record — account, open opportunities, last activity — next to the conversation.
A sample Salesforce Flow pattern
Because message events arrive as activities, you can build on them with standard Salesforce automation. A common pattern: a record-triggered Flow on the Task object that fires when a completed message activity lands, matches the related contact or lead, and updates the record — for example stamping "last message received" on the contact, or moving a lead that replied inbound into a working queue. Service teams route inbound SMS and WhatsApp replies to a queue the same way; sales teams advance the lead status the same way. The integration supplies the trigger object; what the Flow does with it is your tenant's own automation, built with your own Salesforce admin.
If the profile that powers those routing decisions needs to go further than the CRM, that is where the CDP boundary comes in — the CDP vs CRM post lays out where each layer starts and stops.
Where to start
The integration is live in the marketplace today. The /integrations/salesforce page has the same setup steps with the use cases and FAQ, and the CDP vs CRM explainer is the right next read if you are deciding what belongs in the CRM versus the profile layer. Connect with the steps above, run the test message, and your reps stop working around a gap the CRM could never close on its own.