TL;DR
- Team Topologies is built on fracture planes: natural seams you split a system along so each team ships and runs its piece independently. That independence is the point, not the conceptual boundary.
- A single Salesforce org has almost no fracture planes, because everything inside it shares one object model, one order of execution, one per-transaction governor budget, and one deployment target with one test gate.
- So the book applies one level up, at the org landscape rather than inside the org. And its principles invert between the two levels: stream-aligned independence and temporary collaboration fail inside an org and become true across orgs.
- Bounded context is not the same as fracture plane. You can have many domains in one org. You get a real fracture plane only to the degree you have driven coupling across the boundary toward zero, and the platform constantly pushes it back up.
- A product does not start in its own org. It earns its own org when its coupling cost, meaning the shared-object collisions, the coordination, and the shared test gate, exceeds the cost of splitting.
What You'll Learn
- Which Team Topologies concepts transfer to Salesforce cleanly, which need translation, and which actively mislead
- Why a single org resists the book's central mechanism, stated as verifiable platform facts rather than opinion
- How the principles invert between a single-org and a multi-org landscape
- The difference between a bounded context and a fracture plane, and the one-question test that separates them
- A concrete set of criteria for when a product should graduate to its own org
The Problem
Team Topologies has become the default vocabulary for organising software teams: stream-aligned, enabling, complicated-subsystem, and platform teams, interacting through collaboration, X-as-a-Service, or facilitating. It is a genuinely good book, and Salesforce teams reach for it constantly.
Most of those attempts relabel roles and stop there. They call the CoE a platform team and the delivery squads stream-aligned teams, and then wonder why the promised fast, independent flow never shows up. The reason is structural, and it is worth being precise about, because it changes which parts of the book you should use and which you should ignore.
Common Questions This Article Answers:
- Does Team Topologies actually apply to Salesforce, or just its vocabulary?
- Can multiple products or domains inside one org act as independent teams?
- When should a product move into its own org?
Quick Answer
The book's engine is the fracture plane: a seam along which you can split so teams work independently. Inside a single Salesforce org there are almost none, because the platform forces everything to share one object model, one order of execution, one governor-limit budget, and one deployment pipeline. That is a factual constraint, not a design failing.
The consequence, and this is my argument rather than a platform fact, is that Team Topologies applies at the landscape level, across a portfolio of orgs, far more than it applies inside any one org. The orgs are the fracture planes. Inside an org you are below the fracture line, where the book mostly tells you what you cannot do. Across orgs you are at and above it, where it tells you what to do. The same principle, stream-aligned independence for example, is false at the first level and true at the second. A product should therefore live in a shared org until its coupling to that org's shared substrate costs more than a separate org would, at which point it has earned the split.
The facts this rests on
Everything below is argument. This section is not. These are stable, checkable properties of the platform, and they are the evidence the rest of the post stands on. If any of these were false, the argument would collapse, so verify them rather than take my word.
- The object model is shared. Every app in an org sees the same standard objects (Account, Contact, Case, User, Opportunity) with the same fields, and custom objects live in one namespace.
- Order of execution is org-wide, per object. Every trigger, flow, validation rule, and workflow on a given object fires in one platform-defined sequence, regardless of which team or product authored each piece.
- Governor limits are per-transaction and shared. A single transaction shares one budget for SOQL queries, DML rows, CPU time, and the rest, across whatever code and automation it touches.
- There is one deployment target and one test gate. Metadata deploys to the whole org, and a deployment runs the org's Apex tests. Any team's failing test can block any other team's release.
- Platform-wide settings are singular. One sharing model, one role hierarchy, one set of org-wide defaults, one profile and permission-set space.
Those five are the substrate. Hold them in mind, because each one is a place where a boundary you drew inside the org leaks.
Bounded context is not a fracture plane
Here is the distinction the relabelling exercises miss, and it is the heart of this.
Borrow a word from domain-driven design. A bounded context is a conceptual boundary: this set of objects, language, and rules belongs to Product A. You can have many bounded contexts in one org without difficulty. Sales, Service, and a bespoke grants product can all coexist with their own objects and apps.
A fracture plane, in Team Topologies terms, is stronger. It is a bounded context that also delivers independent flow: the team on each side ships and runs without coordinating, and neither can break the other. The independence is the defining property.
So the precise answer to "can multiple products in one org act as fracture planes" is: they are bounded contexts, and they become fracture planes only to the extent that the coupling across them is near zero. In one org, the five facts above mean that coupling is rarely near zero, so the boundaries are usually bounded contexts wearing the costume of fracture planes.
The litmus test settles it in one question: if Product A's team deploys on Friday, can Product B's team deploy the same Friday without coordinating, and can neither break the other's runtime? In a single org the answer is almost always no, because they share the deploy target and the test gate, and because a change to a shared object's fields or order of execution on one side can break inserts on the other. That is true no matter how cleanly the domains were drawn.
The fracture-plane gradient
It helps to stop thinking of "in an org" versus "across orgs" as two states, and see four altitudes of increasing isolation. This framing is mine, not the book's, but it is the most useful way I have found to reason about it.
| Altitude | Isolation | What you get |
|---|---|---|
| Object / shared metadata | None | One trigger order, one limit budget. No boundary at all. |
| Package (2GP / unlocked) | Soft | Ownership and dependency structure, but shared runtime, objects, deploy target. |
| Org | Hard | Own metadata, limits, pipeline, release cadence, identity. A real plane. |
| Landscape (portfolio of orgs) | Hard planes plus integration | Independent products with contracts between them. |
Coupling is the axis that decides where a given boundary actually sits. A product nominally at the package altitude, but sharing Account and cross-object automation with its neighbour, behaves as if it were down at the object altitude. Drive the coupling down and the same package starts to behave like a near-org. The altitude is not fixed by the label you gave the boundary; it is set by how much the boundary actually shares.
The two levels, and why the principles invert
This is the part I find genuinely under-written, and it is my central claim. Team Topologies does not fail on Salesforce. It applies at two levels, and the principles flip between them.
| Book principle | Level 1: inside one org | Level 2: across the landscape |
|---|---|---|
| Fracture planes | Effectively none | Each org is one |
| Stream-aligned teams | Fight over shared metadata; independence impossible | Work cleanly, one team or set per org and product |
| Collaboration mode | Permanent, imposed by the substrate | Returns to temporary: build an integration, then settle into as-a-service |
| X-as-a-Service | Barely available (soft package boundaries) | Correct and natural: published APIs, platform events, integration contracts |
| Inverse Conway maneuver | Little room; architecture is fixed | Genuinely usable: splitting an org is the reverse-Conway move |
| Cognitive load | Bounded by the whole org's surface | Bounded per org; the landscape is how you keep any team's load survivable |
| Fracture-plane criteria | Not applicable | Become your org-split decision criteria |
The collaboration row is the clean illustration. The book says collaboration between teams should be temporary, and treats permanent collaboration as an anti-pattern. Inside a single org that advice is wrong, because shared metadata forces some collaboration to be permanent whether you like it or not. But across orgs the advice becomes right again: two org-teams collaborate to stand up an integration, the boundary then hardens into X-as-a-Service, and they stop coordinating daily. The principle was never wrong. It was being applied at the wrong altitude.
The last row is the practical payoff. The book's own list of where to draw a fracture plane, business domain, regulatory isolation, change cadence, risk, performance, user persona, reads in Salesforce as the checklist for "should this be its own org." Regulatory isolation of health data, a fast-moving product not shackled to a stable one's release train, and performance isolation are the concrete ones. Per-org governor limits in particular mean a high-volume integration workload can justify its own org purely to stop it eating another product's transaction budget, which is a Salesforce-specific instance of a general principle.
Manufacture and defend, until a product earns its own org
Since the platform does not hand you fracture planes inside an org, the architect's job where you want one is to manufacture it and then defend it. That means package boundaries, keeping products off each other's objects, a trigger framework that isolates per-domain logic, and deliberate test scoping. It is real, ongoing work, and it degrades the instant someone adds a shared Account field or a cross-object flow, so it needs governance rather than a one-time design.
The best you can reach this way is the modular monolith: disjoint custom objects, each product in its own unlocked package, minimal shared automation, disciplined test scoping. Deploys still hit one org and run all tests, but blast radius is contained and teams mostly move independently. That is a legitimate and often correct target. It is also synthesized by discipline rather than given by the platform, and there is a hard ceiling: you can never synthesize independent deployment or execution isolation within a single org.
When a product's coupling cost, the shared-object collisions, the coordination overhead, the test-gate contention, exceeds the cost of a separate org, that is the signal to graduate it from a soft in-org boundary to a hard org boundary. A product does not begin life in its own org. It earns one. Stating it that way matters, because the common failure is the opposite: teams split an org early for tidiness and pay the integration and identity tax forever, or they never split and let coupling strangle every release. The decision is a cost comparison, and it has a right answer at any given moment that changes as the product grows.
When an org boundary is the honest answer
The criteria are the book's fracture-plane list, translated. In my experience these are the ones that actually drive the decision:
- Regulatory or data-residency isolation. Health, financial, or jurisdictionally-restricted data that should not share a sharing model or an export surface with everything else.
- Divergent change cadence. A product that needs weekly releases chained to one that changes twice a year, both blocked by the same test gate, is paying a coordination tax that a split removes.
- Governor-limit contention. A high-volume workload that repeatedly threatens another product's transaction budget is a performance fracture plane.
- Blast-radius intolerance. A product where a neighbour's bad deploy causing an outage is unacceptable has outgrown the shared test gate.
- Genuinely disjoint data and users. If two products share almost no records and almost no people, the main argument for one org, the 360-degree view, does not apply.
And the counterweight, because a split is expensive and close to irreversible: a separate org costs licences, integration, identity federation, data duplication, and the loss of cross-product reporting. Unlike microservices, where you can redraw a service boundary in a sprint, moving a Salesforce org boundary later means data migration and rewiring every integration. So the reverse-Conway maneuver works here, but it is a slow, heavy lever with a long lead time, which is the strongest argument for using packages as the reversible middle option before committing to a new org.
What does not transfer
To be fair to the book by being honest about its limits on this platform:
- "You build it, you run it" does not transfer. Salesforce runs the runtime; there is no platform on-call. The nearest equivalent is owning your metadata's post-deploy behaviour and monitoring.
- Independent deployability does not transfer inside an org. Packages help, they do not isolate.
- Team API as a code interface becomes something softer: a metadata ownership map plus integration contracts, closer to a CODEOWNERS discipline than a published service interface.
- Treating all collaboration as temporary misleads at level 1, where some collaboration is structural.
What does transfer, and is worth keeping: cognitive load as the sizing unit, the enabling team that facilitates rather than gatekeeps, the complicated-subsystem team for specialisms like CPQ and OmniStudio, the platform team offering a paved road as-a-service, and the thinnest viable platform as a starting posture. Those five survive contact with the substrate. They are also the ones I leaned on in the delivery team access series, where the admin team is best understood as a platform team and an approval queue as the wrong interaction mode.
Frequently Asked Questions
Q: Can I not just use packages to get independent teams inside one org?
A: Packages get you part of the way and are the right tool, but they do not deliver full independence. An unlocked or 2GP package gives you clear ownership, dependency structure, and modular metadata, which contains blast radius and lets teams mostly work in parallel. What it does not give you is an independent deployment or execution boundary: the package still deploys into one org, shares that org's order of execution and governor limits, and its tests run in the org's single test gate. So packages move a boundary from the object altitude toward the org altitude, but they cannot reach it. Treat them as the reversible middle step, and the best you can do without paying for a second org.
Q: We have five products in one org and it works fine. Is this wrong?
A: Not necessarily. "Works fine" usually means one of two things. Either your products are genuinely low-coupling, sharing few standard objects and little automation, in which case you have effectively built a modular monolith and it can hold for a long time. Or the coupling is real but the coordination cost has not yet become visible, which tends to change the first time two teams collide on a shared object or a deploy, or the first time one product needs a release cadence the shared test gate will not allow. The honest check is the litmus test: can each team deploy without coordinating, and can none break the others. If yes, keep going. If no, you are paying a tax you may not have named yet.
Q: Does the multi-org strategy debate reduce to Team Topologies?
A: It maps onto it more cleanly than either literature usually admits, though I would not say one reduces to the other. The single-org versus multi-org decision is, in Team Topologies terms, a fracture-plane decision: consolidate for the shared data and the 360-degree view, split for autonomy, isolation, and independent flow. Framing it that way is useful because it replaces "how many orgs feels right" with a concrete cost comparison per product, using the book's fracture-plane criteria as the checklist. It does not remove the Salesforce-specific weight of the decision, which is that org boundaries are expensive to create and worse to move.
Key Takeaways
- The org is the fracture plane. A single Salesforce org offers almost no seams for independent flow, because of shared objects, shared order of execution, shared limits, and one deploy target.
- Team Topologies applies one level up. Its principles are strongest at the landscape level, across a portfolio of orgs, and weakest inside any one org.
- The principles invert between levels. Stream-aligned independence and temporary collaboration fail inside an org and become true across orgs.
- Bounded context is not a fracture plane. You can draw many domains in one org; they deliver independence only as far as you have driven coupling to zero.
- Manufacture and defend, then graduate. Synthesize boundaries with packages and discipline inside an org, and split a product into its own org only when its coupling cost exceeds the split cost.
- Separate the facts from the argument. The platform constraints here are checkable; the org-design conclusions are an interpretation of the book applied to them.
What's Next?
Recommended Reading:
- Sizing a Salesforce Access Model for the platform-team and cognitive-load ideas applied to access governance
- A Least-Privilege Access Model for the Delivery Team for how the same tiering logic shapes who can do what across environments
- Salesforce Data Sovereignty in New Zealand for the regulatory-isolation criterion that most often forces an org split
- Salesforce Org-to-Org Migrations for the mechanics once a product has earned its own org
Action Items:
- Run the litmus test on your current org: can each product team deploy without coordinating, and can none break the others. Write down the answer honestly.
- For each product, mark it against the org-split criteria. Note which are trending toward a split rather than sitting still.
- Where you want independence but do not yet warrant a split, decide whether your package boundaries and test scoping are actually defending it, or only nominally.
Resources & References
- Team Topologies, Matthew Skelton and Manuel Pais (IT Revolution, 2019) - the source for team types, interaction modes, cognitive load, and fracture planes
- Apex Developer Guide: Execution order - the order-of-execution fact this argument rests on
- Salesforce Well-Architected - Salesforce's own framing of the single-org versus multi-org decision (see the org-strategy guidance)
About This Guide: This is an argument about org and team design, resting on stated platform facts. Last updated July 2026. The platform constraints are verifiable; the Team Topologies conclusions are the author's interpretation, offered for you to disagree with.
Tags: #salesforce #architecture #teamtopologies #orgstrategy #devops