Every org I’ve worked on that runs both Service Cloud and Marketing Cloud eventually hits the same wall. Someone asks why a customer got a renewal email three days after their case was closed as churned, and nobody has a clean answer. The two clouds aren’t lying to each other. They’re just updating on different clocks, owned by different teams, built for different jobs.
Service Cloud lives in Salesforce’s core data model: Accounts, Contacts, Cases, all transactional and largely real-time. Marketing Cloud runs on its own data extensions, built for send volume at scale, syncing back through Marketing Cloud Connector or an ETL job on a schedule someone set once and forgot about. Put the two together without a plan and you get the classic failure: a customer gets marketed to after opting out through a support case, or a case gets opened for someone who left the business three months ago.
Work out where the truth actually lives
Before picking a sync pattern, decide which system owns which field. Not “both update it.” One owns it, the other reads it. In most orgs I’ve set up, Salesforce core owns identity: who the person is, their account status, whether they’ve opted out, whether they have an open case. Marketing Cloud owns engagement: open rates, click history, journey state, send cadence. The moment both sides think they own “is this contact active,” you’ve built a conflict engine, not a sync.
Write that ownership down somewhere real, not just in your head. A one-page field matrix does it: field name, source of truth, direction of sync, what happens on conflict. I’ve seen teams skip this step and spend three sprints later untangling which system’s opt-out flag actually wins.
The subscriber vs contact trap
Marketing Cloud’s Subscriber and Salesforce’s Contact or Lead are not the same record, even when Connector makes them look like it. A Subscriber Key tied to a Contact ID works fine until someone merges two Contacts in Service Cloud, or a Lead converts into a Contact, and the Subscriber Key doesn’t move with it. Now a subscriber is sending to a dead record while the live one gets nothing. Test your merge and conversion paths specifically for this. It rarely shows up in the happy-path demo.
Pick your sync mechanism on purpose
There are three real options here, and most orgs end up running a mix of all three.
Marketing Cloud Connector
Fine for straightforward orgs: a handful of data extensions, predictable volume, no need for sub-minute freshness. It’s declarative, it’s supported, and it fails loudly enough that you’ll notice when it breaks. Where it struggles is complex filtering logic and high record volume. Watch your synchronized data extension row counts closely. Connector performance degrades in ways that aren’t obvious until you’re already past the point where re-architecting is cheap.
Platform Events and real-time triggers
When a case closure needs to suppress a marketing journey within seconds, not hours, Connector’s batch cadence won’t cut it. Publish a Platform Event when the case closes, and consume it on the Marketing Cloud side through a REST call or a journey entry event. This costs more to build and more to maintain, so save it for the handful of scenarios where timing genuinely matters: opt-outs, churn, anything regulatory. Don’t build real-time sync for data nobody’s waiting on.
Middleware or an iPaaS layer
Once you’re syncing more than two systems, or the transformation logic between them gets complicated enough that it doesn’t belong in either platform’s native tooling, bring in middleware. MuleSoft, Boomi, whatever your org standardises on. The win isn’t speed. It’s having one place to see the whole data flow instead of debugging two black boxes that each assume the other is wrong.
Design for the conflict, not just the happy path
Sync design fails most often at the edges: both systems updating the same field in the same five-minute window, a sync job failing halfway through a batch, a Contact getting deleted mid-journey. Build and test these scenarios on purpose rather than discovering them in production. A contact-centre team I worked with ran a monthly reconciliation report comparing opt-out status between Marketing Cloud and Service Cloud. It caught drift within a day instead of a customer complaint catching it six weeks later.
Error handling matters more here than in most integration work, because the failure mode isn’t a stack trace. It’s a customer getting the wrong experience, and nobody finding out until they complain. Log every sync failure somewhere a human actually looks. A failed Connector job nobody checks for two weeks isn’t a resilient integration. It’s a silent one.
Keep the operating model as tidy as the data model
Technical sync patterns only hold up if the org around them matches. If the marketing team can add fields to data extensions without talking to the Salesforce admin, your field matrix is out of date within a month. Put a lightweight governance step in place: any new field crossing the Service Cloud/Marketing Cloud boundary gets reviewed against the ownership matrix before it ships. It’s a five-minute conversation that saves a reconciliation project later.
None of this needs to be elaborate. A typical enterprise org doesn’t need a real-time event mesh for every field. It needs a clear answer to who owns what, a sync mechanism matched to how urgent each piece of data actually is, and a way to notice when the two clouds drift apart before a customer does. Get those three right and multi-cloud Salesforce stops being a liability. It starts being what it’s supposed to be: one customer view, built from two platforms that are each good at their own job.