Every org running both clouds eventually hits the same argument. Marketing wants the subscriber list clean and current. Service wants the case history complete and fast to load. Somewhere in the middle, a contact record gets updated in one system, doesn’t sync to the other for six hours, and an agent ends up apologising to a customer for an email campaign they already unsubscribed from. Nobody designed for that outcome. It just happens when nobody decided where the data actually lives.
The question everyone asks wrong
The usual framing is “should Marketing Cloud and Service Cloud share a database.” That’s not really the question, and chasing it wastes weeks. The real question is narrower: for each piece of data, which system is allowed to change it first, and which system is just reading a copy. Ownership, not location. Once you separate those two ideas, most of the architecture falls out on its own.
I’ve seen teams spend a full discovery phase debating whether to sync every custom field bidirectionally, when the actual problem was that three fields had two owners each. Fix the ownership model and the sync design gets simple. Skip it and no integration pattern will save you.
Service Cloud owns the case, Marketing Cloud owns the send
Start with what each platform is actually good at. Service Cloud is built around the case object and everything that touches a live interaction: entitlements, SLAs, Omni-Channel routing, knowledge attach, agent productivity. Marketing Cloud is built around segmentation, journey orchestration and send-time optimisation at volumes Service Cloud was never designed to handle.
That split points at a simple rule. Anything that changes because of a conversation with the customer (a case status, a resolution, an escalation, a preference an agent captured mid-call) should be written in Service Cloud first. Anything that changes because of engagement behaviour (an email open, a click, a journey exit, a subscription status) should be written in Marketing Cloud first. Trying to make either system the single source of truth for both kinds of data is where the pain starts.
Where contact data actually belongs
Core identity fields, name, primary email, phone, account association, belong in Salesforce as the CRM system of record. Marketing Cloud should hold a subscriber record that references back to that identity, not a parallel version of it. I’ve worked with orgs that let Marketing Cloud own email address changes because “marketing needed it faster.” Within a year they had two email addresses for a meaningful chunk of their contact base, one in each system, and nobody could say with confidence which one was current. Untangling that took longer than the original integration project.
The sync pattern that actually works
Once ownership is clear, the sync direction should follow it. Core identity and case-driven fields flow Salesforce to Marketing Cloud. Engagement and journey data flows Marketing Cloud to Salesforce, usually as read-only fields an agent can see but not edit. Two-way sync on the same field is where most of the genuinely hard bugs live, because now you need conflict resolution logic, and conflict resolution logic is where a “simple” integration turns into a six-week debugging exercise involving timestamps, retry queues and someone asking why a customer’s phone number reverted itself.
Marketing Cloud Connect vs a custom integration
Marketing Cloud Connect handles the standard case well: syncing contacts, data extensions built from Salesforce reports, and triggering journeys off Salesforce events. If your requirements sit inside that footprint, use it. Don’t build a custom middleware layer to solve a problem the managed package already solves, that’s effort spent maintaining infrastructure instead of shipping outcomes.
Where I reach for something custom is high-volume event-driven sync (thousands of engagement updates a day that Connect’s polling cadence can’t keep up with), or complex transformation logic between the two data models. Even then, keep the ownership rule intact. A custom integration that blurs who owns what is worse than no integration at all, because it looks automated while quietly making the data less trustworthy.
Where Data Cloud changes the calculus
Data Cloud shifts this conversation in a useful direction. Instead of Service Cloud and Marketing Cloud each holding their own partial view and syncing fields back and forth, Data Cloud can sit underneath both as the unification layer, harmonising identity across sources and exposing a single calculated profile to each cloud. That doesn’t remove the ownership question, it just moves it up a level: now you’re deciding which source system is authoritative for each field inside Data Cloud’s identity resolution rules, rather than negotiating a point-to-point sync between two orgs.
It’s worth genuinely evaluating for any org running both clouds at scale, but it’s not a shortcut around doing the ownership exercise. Teams that skip straight to Data Cloud without agreeing on ownership first end up with the same duplicate-identity mess, just inside a more expensive tool.
A decision test that holds up in practice
When a new field or object comes up in a design session, I ask one question: what event causes this data to change? If the answer is a customer interaction an agent is part of, it belongs in Service Cloud. If the answer is a marketing behaviour, an open, a click, a journey stage, it belongs in Marketing Cloud. If the answer is genuinely both, that’s a signal the field is doing two jobs and probably needs to be split into two fields with two clear owners.
Apply that test consistently and the integration design writes itself. Skip it and you’ll be back in six months arguing about why the unsubscribe list and the case queue disagree with each other, and nobody will remember which system was supposed to be right.