Org Strategy Is a Landscape Decision

🌐 Also in 28 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 5 of 6 in the chapter Understanding Enterprise Data, chapter 4 of the Data Architect course. Each module stands on its own. Previous: Draw the System Landscape · Next: Steve Trucking’s Landscape

The question this module answers: One org or many, and where does it run?

When I teach CTA candidates, I tell them the biggest decision in a scenario comes in the first five or ten minutes: how many Salesforce orgs are we dealing with? One big org? Regional orgs for North America, EMEA and APAC? Separate orgs for separate business units? A special org for a country with its own rules? And tied straight to it: where do those orgs run?

These aren’t admin details. They change where the data lives, the integrations, reporting, identity, and how people around the world reach the system. That’s why I treat org strategy as a landscape decision, and why I make it first.

Start With One Org

My starting position is simple: start with one org. Not because one org is always right, but because I need a reason to add another. One org gives me one place for shared customer data, one security model, one place to deploy, one set of integrations, one place to report. And one org can still support different business units, countries, processes, record types, apps, sharing models and experiences.

So I don’t add an org because Europe does things a little differently, or a division has its own sales process, or the business units don’t like each other. Those are requirements, not org boundaries. The question is: what force is strong enough to justify another org?

Multiple Orgs Have a Cost

Split one org into three (North America, Europe, Asia-Pacific) and you haven’t drawn three neat boxes; you’ve created new questions. Where does a global customer live? What if it operates in two regions: two copies, and which one owns it? How does anyone report globally? Does the ERP integrate with all three, does the warehouse get three feeds, does the identity provider connect to all three? Do we deploy the same functionality three times and keep three data models aligned? If an agent needs a global view of a customer, which org does it ask?

Go back to the landscape from module 4. One Salesforce box becomes three, and every arrow gets redrawn. Multi-org isn’t wrong. It’s never free.

Look for Real Boundaries

What can justify another org? Boundaries real enough to shape the architecture: data residency, regulation, legal separation, genuinely different operating models, an acquisition that hasn’t converged yet, a regional hosting constraint, very different governance, sometimes scale or isolation. The list isn’t complete. The point is to tell “these groups are different” apart from “these groups need an architectural boundary.” The second bar is much higher.

Geography Isn’t Automatically an Org Strategy

“We operate in 30 countries, so we need 30 orgs.” No. Geography matters when it brings an architectural requirement. A company can have users all over the world on one common architecture. So I don’t count countries; I ask what comes with them. Where may the data be stored? Where may it be processed? Are there limits on moving personal data across borders? Contractual promises about residency? Does a region need a different Salesforce service or host? “There’s an office in Germany” isn’t enough on its own.

Hosting Is Part of the Drawing

Here the modern platform makes the landscape more interesting. Hyperforce runs Salesforce on public cloud infrastructure in regions around the world, giving customers more choice and control over where their data resides (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). So when I label a box “Salesforce, Europe,” that location can matter.

But be precise. Choosing where an org lives is not a promise that every byte of every service stays there. Salesforce tells customers to review the trust and compliance documentation for Hyperforce, including the additional sub-processors for the services they buy (same source). So don’t say “we’re on Hyperforce in country X, so everything stays in country X.” Know which services you’re actually using, and which requirement you’re satisfying. And notice what you choose: the region, not the cloud underneath it. Hyperforce runs on AWS, with Google Cloud from late 2026, and Salesforce decides which provider an org sits on; a customer with a documented regulatory reason to avoid one talks to its account team (same source).

Don’t Play Lawyer

This is also where architects need to know their role. If someone says, “European privacy law requires a separate org,” I won’t accept it blindly. I also won’t appoint myself the company’s lawyer and declare that it doesn’t. I’ll ask: what specific requirement are we satisfying? Where data is stored, where it’s processed, cross-border transfer, who can access it for support, a contract, internal policy? Then I work with privacy, security, compliance and legal to turn that requirement into architecture. Don’t make up legal requirements, and don’t ignore them. Translate them.

When Europe Gets Its Own Org

Here’s a boundary I see in real scenarios. A company has a heavy presence in the US and a heavy presence in Europe: two large customer bases, two sales and service operations, and a European privacy program built around GDPR. GDPR doesn’t say “you need a separate Salesforce org.” It sets rules for personal data, including when it may be transferred out of the EU (GDPR, Chapter V (opens in a new tab)). But this company, working with its privacy and legal teams, decides that its European customers’ personal data should live in an org hosted in Europe, run by its European team, under its European governance. That’s a real requirement, and it’s theirs, not mine.

Now “one big global org” isn’t a preference any more. There’s a boundary on the landscape, Salesforce AMER and Salesforce EMEA, and I have to draw it. And the second org is never just one more box.

Click to enlarge

Two orgs, AMER and EMEA. The amber is what the second org adds: not one more box, but every arrow again.

Walk the Arrows Again

With more than one org, walk the landscape again. Does the ERP send products to every org? Does each one send orders back? Where are customers mastered, and may their data cross regions? Is the integration layer global or regional? Which identity provider signs in which users? Where does analytical data go?

Three places show the cost fastest:

Reporting. The CEO wants a global pipeline. In one org, that’s a Salesforce report. In three, it’s an enterprise reporting problem: replicate, send to the warehouse, federate? How current must it be, and do the orgs even define “pipeline” the same way? Where analytics lives follows where the data lives, and if you split the operational data on purpose, you have to design how insight comes back together.

Master data. A global customer buys in the US, Germany and Japan. Three orgs, so probably three Accounts. How do you know they’re the same company? What’s the global identifier, and who owns it? If one region changes the address, should it spread? Which attributes are global and which regional? Org strategy doesn’t solve identity; it changes the identity problem. That’s chapter 6.

Integration. One org: Salesforce, the integration layer, the ERP. Three orgs: three connections into the integration layer, perhaps one with its own host and connectivity, some flows shared, some regional, some data allowed across and some not. Even the network can change: if the enterprise needs dedicated private connectivity into Hyperforce (on AWS, Salesforce recommends AWS Direct Connect; same Hyperforce FAQ), every org and host on the drawing is another connection to plan. Where an org runs can change how the rest of the enterprise reaches it.

One org or many is a decision you make now, at the start, on the landscape. How the orgs then share data (cross-org Salesforce Connect, integration between them, Data 360) is the mechanics, and chapter 14, One Org or Many? (coming soon), covers it.

If you design the whole data model and integration architecture and only then hear “by the way, this has to be three orgs,” you haven’t made a small adjustment. You’ve changed the architecture. That’s why the decision comes first.

Don’t Split Just to Make the Boxes Smaller

A big org feels complicated: lots of units, objects, users, integrations. Someone says, “Wouldn’t it be cleaner if everyone had their own org?” The drawing might get cleaner. The enterprise may not. You’ve traded internal complexity for distributed complexity: synchronization, duplicate data, cross-org identity, global reporting, several release pipelines, duplicated integrations and automation, and governance over all of it. Sometimes that’s still the right trade. But separate isn’t the same as simple.

And one org isn’t free either. Shared governance matters more, teams can affect each other, security boundaries need careful design, the data model has to serve many groups, releases need coordination, and regional rules can constrain everyone. So it isn’t “Steve says always one org.” My starting bias is one org; then I look for the requirement strong enough to move me off it.

Make the Decision Visible

If org strategy matters, don’t draw a generic Salesforce cloud. Draw the orgs and label them (AMER, EMEA, whatever’s real), note the hosting or residency requirement behind each, and walk the connections. Another architect should be able to see why each boundary exists. If I can’t explain why there are three Salesforce boxes, I haven’t finished the decision.

Steve Trucking runs one org, in the US, and nothing in its brief calls for another. But keep this module in mind for the capstone: an acquisition that arrives with its own org is exactly the kind of boundary that tests these questions.

Beyond the exam: what AI changes. An agent can make an org boundary invisible to the user. Underneath, the architecture still has to decide which org or system the agent may ask, what data may cross regions, and which answer is authoritative. AI can hide the complexity in the experience; it doesn’t remove the governance or the boundary.

What an Architect Decides Here

• Whether there’s a genuine architectural reason for more than one org, rather than solving the differences inside one.
• Where each org runs, and which residency, regulatory, contractual or business requirement puts it there.
• Which data may cross org and regional boundaries, where master data is authoritative, and how global identity works.
• How integration, identity, analytics and reporting change when one Salesforce box becomes several.
• Whether the benefit of separation is worth the distributed architecture it creates.

When I read a scenario, I look for this decision first: one org or many, hosted where, and forced by what? Answer those, and the rest of the landscape starts to take shape.

Explore

• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab), checked 2026-10-14.
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab), Chapter V (transfers of personal data to third countries), checked 2026-10-14.