Connecting Sales, Service, Data and AI in a Multi-Cloud Salesforce Architecture

#The problem, as it actually presented

Nobody asks for a multi-cloud architecture. They ask for three things in the same quarter. Sales wants a pipeline they can forecast. Service wants to stop asking people to repeat themselves. The board has asked what the AI plan is, and would like an answer before the next meeting. Sales Cloud, Service Cloud, Data 360 and Agentforce is a defensible response to those three requests taken together, and it is usually how the licence order gets its shape.

The trouble starts at the first joint design session, when somebody writes the word customer on a whiteboard and three people in the room mean three different things by it.

For a brand selling both direct and through retail partners, that is not sloppiness. It is an accurate description of how the business works. Sales manages trade accounts: a supermarket group, a distributor, a regional chain, each with named buyers, commercial terms and a territory. Service takes calls and emails from the person who owns the product, who in most cases the brand has no commercial relationship with at all. Marketing holds email addresses with consent states, gathered at storefront checkout, from competitions and from warranty registration, and a large share of those people also appear in service and appear nowhere in sales.

That is three customers. A trade account. A consumer who bought direct. A consumer who bought at retail and only becomes visible when something goes wrong. Each of the three teams is describing something real, and none of them is describing the other two.

#The one decision that determines everything downstream

Who owns the customer record.

Not which system stores it. Ownership in the sense that matters is the authority to settle a disagreement: when service wants a field on the consumer record that sales does not want on the trade record, when marketing wants a person created from an email address alone and service wants proof of purchase first, somebody has to decide, and that decision has to hold. Naming a system as master without naming a person is the most common version of this failure, because a system cannot arbitrate.

Two questions have to be answered together, and answering only the first is what produces an architecture that looks correct on a diagram and argues with itself in production.

What is a customer. In this estate the honest answer is that there are two shapes and they are not variations of each other. A trade account is an organisation with buyers, terms and a hierarchy. A consumer is an individual with a purchase history that may be partly invisible to the brand. Modelling both as the same object because the word is the same is how a programme ends up with an Account record type nobody can explain and reports that quietly double count.

Who arbitrates. One named person, senior enough that their own objectives move if the programme goes badly, who will be asked roughly every fortnight for the life of the work. If nobody will take that, the programme is not ready to start, and starting anyway means the trade-offs get settled by whoever is in the room, optimising for the thing they are measured on.

Our wider view on this is in the implementation mistakes ranked by what they cost to undo. The relevant part here is that the expensive mistakes are organisational and cannot be retrofitted. This is the multi-cloud version of exactly that.

#Identity resolution as the foundation everything above it inherits

Once the definition is settled, Data 360 does the part that no operational cloud can do on its own: it takes records from systems the organisation does not fully control and decides which of them describe the same person.

That decision is a business judgement wearing technical clothing. Matching rules encode how confident you have to be before two records are treated as one human being, and both directions of error are expensive in different ways.

Set the rules too loosely and two members of one household who share a surname, an address and a delivery preference collapse into one profile. Their orders merge, their consent states merge, and one of them starts receiving communication the other consented to. In a consumer brand that is a complaint, and depending on jurisdiction it is a reportable one.

Set the rules too tightly and the same person remains three profiles: the storefront order, the warranty registration and the contact centre call. Nothing breaks visibly. Every count downstream is simply wrong, in a direction nobody can quantify, and the service agent still asks the customer to repeat themselves, which was the problem the programme was funded to solve.

There is no setting that avoids both. What a good design does is decide which error it prefers, in writing, and route the ambiguous cases to a human review queue rather than to a confident automatic decision. A queue reviewed daily is far cheaper to run than the alternative, which is discovering a year later that a segment of the profile base is silently wrong.

Two further points that get missed in the design and found in production.

Resolution is not a one-off. Rules get tuned, sources get added, and reprocessing moves people between profiles. Anything built on top has to tolerate a profile changing shape, which means downstream systems reference the resolved identity rather than caching a copy of it.

Confidence is an attribute, not a hidden implementation detail. If a profile was assembled from a weak match, whatever reads it should be able to know that. This becomes the difference between a usable AI layer and a dangerous one.

#Why grounding on an unresolved identity is worse than a hallucination

The AI layer is where the whole design is graded, and it grades harshly.

An agent grounded on a properly resolved profile can tell a consumer where their order is, whether their warranty is live and what was said on their last call. An agent grounded on an unresolved identity does the same thing with the same confidence and gets it wrong, because the profile it read was assembled from a bad match or was missing the half of the history that sat under a second profile.

That failure mode deserves to be named precisely, because it is routinely mislabelled. The model did not hallucinate. It reported faithfully what the data told it. That is worse than a hallucination in every respect that matters commercially: it is fluent, it is specific, it is internally consistent, and it is defensible by the system right up to the moment a customer is told about somebody else's order. A hallucination sounds like a machine being wrong. This sounds like the brand being wrong.

Which is why grounding is scoped to the identity layer and never to a source system. A connection from an agent straight to the storefront platform is faster to build, demonstrates well, and skips the only step that makes the answer trustworthy. Our Agentforce implementation guidance covers the retrieval and escalation design in more depth; the multi-cloud specific rule is narrower. The agent may read the resolved profile. It may not decide who a person is.

#Sequencing, and why parallel delivery is four mistakes at once

Every plan for this shape of work arrives with four workstreams running side by side, because that is what the timeline demands and because four teams genuinely can build at the same time.

The dependency is not on code. It is on decisions, and decisions do not parallelise. Four teams working simultaneously will each invent a customer definition, a set of picklists, an integration pattern and a permission model, all reasonable within their own scope. The integration phase that follows is not integration. It is renegotiation, conducted late, between teams who have all already built.

The sequence that works has the definitional work in front and the demonstrable work behind it, which is the opposite of what a steering committee wants to see.

Settle ownership and the customer definition first. This is a facilitated argument rather than a workshop, and it produces a short written document that survives the programme.

Land one operational cloud properly. Usually the one with the clearer existing process. A first cloud can be built on almost any model and still look fine, which is exactly why it is not the test.

Bring Data 360 in against real data from a live cloud. Identity resolution designed against a hypothesis is a guess. Designed against a live source it becomes an argument about specific records, which is a much better argument to have.

Land the second cloud onto the resolved identity. This is where the design is actually tested, because it is the first time two processes have to agree about the same person.

Ground the AI last. Not because AI is an afterthought, but because everything that makes it safe is built in the four steps above.

#Where the clouds should share an object, and where sharing is the mistake

Multi-cloud design is often taught as an exercise in maximising reuse. That instinct is right about half the time and expensive the other half.

Share an object when two clouds need the same fact about the same real-world thing and would otherwise diverge. Product and Asset qualify: the item a consumer is complaining about is the item the trade account bought, and two catalogues would be a defect waiting to happen. Consent and preference qualify emphatically, because consent is a platform obligation rather than a marketing feature, and a service agent needs to see the same state a campaign respects. The resolved identity qualifies by definition.

Do not share an object when two clouds need the same word for two different facts. The recurring example is status. A shared status picklist spanning opportunity stage and case state looks tidy on a data model and is unusable within a month, because the two lifecycles have nothing in common except the noun. The same applies to a shared customer health object that everyone contributes to and nobody owns, which reliably becomes a field nobody trusts and nobody will delete.

The test we apply is ownership rather than similarity. If the two clouds would need different owners to change the same field, it should not be one field. Similar shape is not shared meaning.

#The governance that has to exist before the second cloud lands

Governance in a single-cloud org can be added late at moderate cost. In a multi-cloud estate it is the retrofit that turns into a programme, because by the time the second cloud is live there are two teams, two backlogs, two release rhythms and two versions of the customer, and correcting it means telling one team their design was wrong after they shipped it.

What has to be in place before the second cloud arrives is small and specific.

A named owner for every shared object, recorded where the next administrator will look. One change process spanning both clouds, so a field added to Account is visible to the team who did not add it. A shared release calendar, because two independent release trains touching one object is how a Friday goes badly. A written and versioned definition of the customer, treated as a controlled document rather than as a slide. And consent state as a platform-level obligation with one owner, not a setting each cloud interprets locally.

None of that is expensive at the point it is needed. All of it is expensive afterwards, which is the entire argument.

#The decisions that were contested

Not making Data 360 the system of record for everything. There was genuine appetite for it, on the reasonable grounds that it already holds the most complete view. We argued the opposite: it should own identity and nothing else. The moment it also owns process, it becomes a second system of record that nobody agreed to govern, and every question about where a fact lives gets harder rather than easier.

Refusing to launch the agent alongside the second cloud go-live. The date was attractive and the pressure was real. The objection was that grounding quality cannot be assessed until the resolved profiles have run against live volume for a while, and the cost of finding that out publicly is far higher than the cost of a delayed announcement.

Modelling the trade account and the consumer differently. The tidier design gives them one shape. The business reason not to is that they have different lifecycles, different owners, different consent obligations and different reporting audiences, and flattening them produces an object that serves neither well.

Keeping two identifiers on purpose. People wanted one customer number. There is a resolved profile identifier and an operational record identifier, and they answer different questions: who this person is, and which record a process is acting on. Collapsing them sounds like simplification and is actually the loss of a distinction the design depends on.

#What changes

The outcomes worth claiming here are operational, and they follow from the sequence and the ownership decisions rather than from effort.

The second-order effect is the one leaders notice. Cross-team meetings stop being about whose data is right. When both clouds refer to the same resolved identity, the conversation moves to what to do for the customer, which is the conversation the programme was funded to enable.

#What we would tell you before starting

Start with the definition, not with the platform. If you cannot name the person who will settle a disagreement between sales, service and marketing about what a customer is, you do not have an architecture problem yet, you have an organisational one, and buying a fourth cloud will not resolve it.

Then be honest about the sequence. The pressure to run everything in parallel is real and it is always defended with the timeline. The timeline is not what four parallel workstreams put at risk. What they put at risk is arriving at integration with four incompatible answers to a question nobody was assigned.

And most organisations should not start with four clouds. If you sell through one channel, identify customers by one stable identifier and have one team who owns the relationship, this design is over-engineering, and a single well-governed cloud will serve you better for years. The architecture above earns its cost when identity genuinely fragments across systems you do not control, when two operational teams have to act on the same person, and when something is going to be grounded on the result. If the second cloud is a budget line for next year rather than a committed plan, wait. If AI is the reason for the programme rather than a consequence of getting the identity right, that is the strongest signal of all that the sequence is upside down.