The programme is late and the status report says alignment. Underneath that word there is normally one specific definition nobody has the authority to settle.

Only if the merit argument holds, and often it does not. Multi-org estates are usually the record of a corporate history rather than an architecture failure: each acquisition arrived with an org and each org had a reason. Consolidation is genuinely right when the same customer is served by several business units, when regulatory reporting spans them, or when the cost of maintaining parallel processes exceeds the disruption of merging. It is genuinely wrong when the orgs serve different regulatory regimes, different business models or different customers who never overlap. We survey what exists first and give you the answer with a number attached, including when the answer is to leave it alone and invest in the integration between them instead.

In our experience, almost never on technology. They stall where a decision is required and nobody has the authority to make it. Two functions define a qualified opportunity differently, or finance and sales disagree on when revenue is recognised against a record, and the work stops at that point and resumes as a workshop about alignment. The fix is structural rather than technical: name one decision owner per contested term, give them the authority, and write the outcome down. That single item unblocks more enterprise programmes than any architectural change we have made.

As an engineering commitment rather than as three projects. Organisations that treat each release as an event spend a surprising share of their annual capacity on regression testing and negotiation with the calendar. The alternative is automated regression coverage on the critical paths, a preview-window process that reads release notes against what your estate actually uses rather than in full, and a standing owner. That turns most releases into a page of decisions. It is upfront investment, and it pays back within about a year at enterprise scale.

By treating it as information rather than as indiscipline. When a team maintains a parallel record, they are telling you the platform does not support how they actually work, and the spreadsheet is usually a precise specification of the gap. Policing it removes the evidence without removing the cause, and the work simply moves somewhere less visible. We go and read those spreadsheets. It is the cheapest requirements-gathering available, and it routinely surfaces a genuine process the platform was never configured to support.

Both are legitimate and the answer depends on reuse and governance rather than on volume. MuleSoft earns its cost when many systems are involved, when the same interface has several consumers, when there are audit obligations that need policy applied centrally, or when an agent programme needs a controlled way to reach everything. Native tooling, Flow with callouts, External Services, Platform Events and Salesforce Connect, does the job for a modest number of point-to-point requirements and comes with licences you already own. We map the requirement against both. Our MuleSoft integration services page covers how we scope the larger version.

Four things, and none of them is a tool. Somebody owns each critical definition and has authority to settle disputes about it. Lineage is documented for the fields that drive decisions, so when a number is challenged there is an answer rather than an investigation. Retention and residency are decided deliberately rather than inherited from whatever the first implementation did. And data quality is measured and published rather than asserted. That last one matters most before an AI programme, because an agent grounded on a customer profile assembled from unowned data will state something confidently that nobody can defend.