The single screen nobody was going to use
Every shared customer record project I have reviewed started with the same slide. One customer, one view, one truth. The one I remember best had sales on Sales Cloud and service on Dynamics 365 Customer Service, and the proposal was to give both teams the same account page. Sales pushed back hard. They did not want open cases and warranty dates on the page where they work a pipeline, and service had no use for opportunity stages or forecast categories.
What both teams needed was smaller and harder. They needed to agree which customer they were both talking about, what state that customer was in, which system was allowed to change which field, and where a wrong value went to get fixed. None of that requires a shared screen. All of it requires a shared set of rules, written down, with a name against each one.
So when the single view got shelved, the useful work started. What follows is the work that replaced it, and what I would say if you are about to sit through the same slide.
Agree on the identifier before anyone opens a field list
The first argument is which record is the customer. Sales Cloud has an Account with an eighteen-character ID. Dynamics 365 has an account row with a GUID. Neither of those means anything to the other side, and neither survives a re-implementation. On the project I am describing, the integration had matched on company name for two years, and a company that had been acquired and renamed existed four times, twice in each system.
The fix was plain. Billing already issued a customer number, finance read it out on the phone when they chased invoices, and both CRMs could hold it. Sales Cloud gets an External ID text field marked unique, Dynamics 365 gets an alternate key on the same column, and the sync matches on nothing else. Our field guide to durable business keys covers how to choose that number and what to do when a record has none yet, so I will only add the meeting-room version. If the two teams cannot name the same identifier, stop the project until they can.
Lifecycle states are where sales and service actually disagree
Identifiers are the easy fight because there is a right answer. Lifecycle states are the hard one because both teams are right. Sales sees a customer as Prospect, Open, Won or Lost. Service sees a customer as Under contract, Out of contract, or On hold for non-payment. On the project, a service agent opened a case for an account that sales had marked Closed Lost eight months earlier, and the SLA timer started against a contract that no longer existed.
I do not try to merge those two lists. Each team keeps its own working status on its own screen. What they share is a short list of states that both systems respect, with one owner each. Whether we have a live commercial relationship, owned by sales. Whether we are obliged to support them, owned by service. Whether the record is retired, owned by whoever runs data. Three shared flags with three owners, and every other status stays local.
The test I use in the review is to read a state aloud and ask who is allowed to change it. If the answer is both, you have two local states with the same name, and the sync will fight over them within a month.
Write down which change wins
When two systems can write the same field, something decides which write survives. If nobody wrote that decision down, the decision is whichever job ran last. On the project, service updated a customer's main phone number after a call, the nightly sync from Sales Cloud put the old number back, and the next agent rang a disconnected line. Nobody had chosen last-writer-wins. It chose itself.
The rule I push for is ownership by field, on a short list. Sales owns the fields sales collects, such as primary contact, segment, and account owner. Service owns the fields service learns on the phone, such as support contact, site address, and preferred language. Fields both teams genuinely change, such as that main phone number, get one owner and a request path for the other side. It is fine for the owner to be whichever team spoke to the customer most recently, as long as that is the written rule and the sync carries a timestamp and a source system so it can enforce it.
Keep that list short and versioned. Small integration contracts are easier to defend than wide ones. A conflict rule covering twelve fields will get read. One covering two hundred will get a nod in the meeting and no attention afterwards.
A disputed update needs somewhere to go
Even with a good conflict rule, some updates are wrong and someone will notice. A service agent sees that the address the sync just wrote over was the one the customer confirmed on the call. On most projects, what she does is edit the field, the sync overwrites it again that night, and she stops trusting the record. That is the moment a wrong field becomes a support problem rather than a data quality one.
The correction path is three written facts per owned field. Who can change it, which system holds the version that wins, and where a disputed value goes for review. The third one is where projects go quiet. A Power Automate flow or a Salesforce Flow can route the dispute, but the queue is not the owner. Someone with a name has to look at the two values, decide, and record why. On the project it was the service team lead for anything service-owned and the sales operations analyst for the rest, and disputes landed in a Dataverse table both of them could see.
Volume tells you whether the rules are working. If that review table gets more than a handful of rows a week, the conflict rule is wrong and the fix is upstream. If it gets nothing for a month, check that disputes are being raised at all rather than quietly re-keyed by whoever noticed.
What to say in the meeting
When the single-view slide comes up, the sentence I use is that the teams can keep their screens if they sign the rules. Then I put four questions on the whiteboard and refuse to discuss integration tooling until they have answers. Which number identifies a customer in both systems. Which states does each team promise to respect, and who owns each one. For each shared field, whose write wins. When a value is wrong, who fixes it and where is the dispute recorded.
The answers fit on one page. They should be signed by the head of sales and the head of service, because those are the two people who will be in the room when the record is wrong and a customer is on the phone. Most of what is written on the CRM hub about agents reading customer data assumes that page exists. On most projects it does not.
So before the next sync is built between Sales Cloud and Dynamics 365, ask for that page. If nobody can produce it, the shared customer record does not exist yet, whatever the diagram says, and the first deliverable is the page.
