When Nobody Chose: How Salesforce Org Sprawl Happens and Why It's So Hard to Unwind
I once sat in a room with two senior managers from the same government organisation. One ran a facilities help desk — the team that responded when a desk needed fixing or a building had a maintenance issue. They'd built their operation on Salesforce six or seven years earlier, using it to manage and track service requests across the organisation. The other managed a network of not-for-profit affiliates — community organisations the agency supported and coordinated with across different areas of social need. They'd also built on Salesforce, more recently, and almost certainly through a partner rather than directly with Salesforce.
Same organisation. New Salesforce Account Team — me, as it happened. The facilities org had been built six years ago. The community org only last year. These were completely separate orgs, completely separate contracts, and — until that moment — no awareness from either team that the other was using Salesforce.
This wasn't negligence. It was logic. The organisation had a deliberate policy of pushing responsibility for business unit applications, and the spend that went with them, out to the business units themselves. That's a sensible governance model in many respects. Why would the enterprise care about a real estate maintenance application? It served a narrow operational need, it was self-contained, and its costs were manageable at the BU level. The same was true of the affiliate management system. Neither team had any reason to interact with the other. Each had solved its own problem with the tools available.
What neither team — and, for a period, nobody at the enterprise level — had recognised was that they were both running on the same technical platform. Not just using similar software. Running on Salesforce, with all that implies for data architecture, integration potential, licensing mechanics, and long-term platform strategy.
That's not an outlier. That's exactly how the org strategy problem starts.
The previous article in this series covered the three org models — single, multi, and hybrid — what each one means, and how to choose between them before events choose for you. This article is for organisations that are already past that point. The structure accumulated without a plan. The problem is here. This article explains how that happened, why it's so hard to unwind, and what the arrival of Data Cloud and Agentforce means if it hasn't been resolved yet. The next article covers what to actually do about it.
How you got here
The standard narrative around Salesforce org strategy assumes that someone made a choice. Single org, multi-org, hybrid — the architectural decision frameworks discuss these as deliberate options, weighed up in a room with whiteboards and clear requirements.
That is rarely how it happens.
What actually happens is that Salesforce enters an organisation piecemeal. A business unit needs a CRM. They buy Salesforce. Another business unit is doing field service. They have a budget and a deadline and someone recommends Salesforce. A third is spinning up a customer portal. They go to a different implementation partner, get a different recommendation, sign a different contract.
Nobody is making an enterprise decision. Each team is making a local one. And for a while, that's fine — each business unit has what it needs, the contracts are modest, and the complexity is invisible because the business units aren't talking to each other.
Then, gradually, it isn't fine.
The data starts to diverge. A customer exists in three orgs with three different addresses and three different service histories. The integration team is asked to connect the sales org to the service org, and discovers that the data models are incompatible. Procurement gets the renewal notices and realises they're paying materially different rates for the same licences — because each contract was negotiated at a different point in time, by different people, without reference to what the others were paying.
And architecture eventually surfaces the problem in its forums: this is getting unmanageable.
That's the moment the org strategy conversation begins. Not at the start. Years in.
What you're actually dealing with
The mess that accumulates from unplanned multi-org growth is both commercial and technical, and the two are tangled together in ways that make it harder to address.
On the commercial side: Multiple contracts mean multiple renewal dates, multiple negotiating histories, and — almost inevitably — pricing inconsistency. (For a frank account of how that renewal dynamic works from Salesforce's side of the table, see What's Really Happening in Your Salesforce Renewal.) The same Sales Cloud Enterprise licence might cost one business unit significantly more than another, because one contract was signed three years ago when discounting was more aggressive, and another was signed last year when the account team had different targets. Nobody at procurement level has visibility across all of them until the problem is acute. By then, the cost of the inconsistency has been running for years.
There's also the integration cost — the middleware, the licences, the maintenance overhead required to connect orgs that were never designed to talk to each other. This cost is real and it's often buried in IT budgets where it's not visible to the commercial conversation. When it does get surfaced, it's usually because the business pain has become impossible to ignore: duplicate data causing customer service failures, reporting that can't reconcile across orgs, projects stalled because nobody can agree on which record is the source of truth.
On the technical side: Each org has its own metadata, its own data model, its own customisations. The longer they've been running independently, the further they've diverged. Consolidation — if that's where things end up — requires decisions about which data model wins, how historical data migrates, and what happens to the customisations in each environment. These are significant technical undertakings, and they're not cheap.
The reason both sides of this problem persist for so long is that there's no single owner who sees the full picture. The business unit leaders each see their own org. Procurement sees the contracts but not the architecture. Architecture sees the technical mess but doesn't have commercial visibility. The Salesforce account team may actually have the clearest view — they can see all the contracts from their end — which is sometimes why they're the ones who first surface it to the CIO.
Why fixing it is so hard
When the conversation finally happens — when the CIO or the procurement lead calls everyone into a room — the reaction from the business unit owners is almost always the same: resistance.
This is rational, not obstinate. Each business unit has built its Salesforce instance around its own processes, its own team, its own workflows. The idea of centralising — of handing control of "their" platform to some enterprise function — feels like a genuine loss of autonomy. And it probably is. That's a real cost, not a perceived one.
The political dynamics are genuinely difficult. A BU leader who has been running their own Salesforce environment for five years, who has their own admin, their own roadmap, their own relationship with their account team — they will not easily accept the proposition that this should be folded into an enterprise model governed by someone else. "I don't have a problem" is a reasonable position from where they're standing. The problem is visible from the procurement office. It's visible from architecture. It's visible from the Salesforce side. But from inside a well-functioning business unit instance, it looks like someone else's problem.
This dynamic is why the outcome of most org strategy conversations is not full consolidation. It's a hybrid model, or a formalised multi-org model, or some variant thereof — because that's the pragmatic outcome when consolidation is technically justified but politically impossible. It's not always the right answer. It's usually the only achievable one.
What makes even that harder is that there's typically no executive sponsor in place when the conversation starts. The CIO is aware of the problem. The CFO doesn't understand it yet. There's no Salesforce platform owner with enterprise-wide authority, because that role doesn't exist — it couldn't exist until someone recognised that the platform needed one. Creating that role, defining its authority, allocating it budget — that process takes time and doesn't happen overnight. And without it, the org strategy conversation stalls, because nobody has the mandate or the resources to drive it to completion.
What Data Cloud and Agentforce change — and what they don't
Salesforce's recent product trajectory makes the unresolved org structure problem significantly more consequential.
Data Cloud — Salesforce's unified data platform — is positioned as the answer to the fragmented data problem. It can aggregate data from multiple orgs into a single place, resolve identities across disparate records, and provide a unified customer view. If you have data scattered across three Salesforce environments, Data Cloud offers a path to connecting it.
But it doesn't resolve the underlying issues. Data Cloud addresses the symptoms — the fragmented data — without addressing the cause, which is the uncoordinated org structure that created the fragmentation in the first place. You can layer Data Cloud on top of an unresolved multi-org mess, and you'll have better data visibility than you had before, but the governance problems, the commercial inconsistencies, and the integration overhead will still be there. And Data Cloud is not cheap — you're adding a meaningful new licensing layer to a situation that already has commercial complexity.
Agentforce amplifies this. Agentforce agents operate within and across Salesforce orgs, and their effectiveness depends significantly on the quality and consistency of the data they're working with. If your orgs are well-architected — if you've done the work to rationalise your multi-org environment into a coherent structure with clear data flows — Agentforce can do meaningful work across that structure. If your orgs have grown organically and never been properly addressed, the agent can't reliably reconcile what it finds, and the results are unpredictable.
There is a risk — and it's a real one — that organisations use Data Cloud and Agentforce investment as a way of avoiding the harder conversation. The technology is compelling, the vendor narrative is sophisticated, and buying a product feels like progress. But buying a solution for a symptom is not the same as addressing the cause. If your house has a structural problem, putting better plaster on the walls is not the answer. The org strategy conversation still has to happen.
What that conversation looks like, who needs to be in the room, and what it actually takes to move from where you are to somewhere better — that's the subject of the next article in this series.
Mike Roberts spent over eight years at Salesforce, including time as a Strategic Account Director, before founding Aequus Consulting. He works with New Zealand organisations on Salesforce licence optimisation and renewal preparation, with no vendor affiliations.