Org Strategy: Quick Reference
The org strategy decision is the highest-stakes call in system architecture. It is irreversible (merging orgs is brutally expensive) and it determines the blast radius for every subsequent choice — security, data, integration, licensing, governance.
Default answer: single-org. Multi-org needs a documented, compelling reason.
Single vs Multi-Org Decision Table
| Signal in Scenario | Decision | Why |
|---|---|---|
| Shared customers across BUs | Single-org | 360-degree view without integration |
| Shared sales teams | Single-org | One pipeline, one forecast |
| GDPR/data residency that Hyperforce solves | Single-org (Hyperforce) | Data stays in-region without org split |
| GDPR/data residency Hyperforce cannot solve | Multi-org | Hard regulatory requirement |
| FedRAMP / IL4+ / ITAR | Multi-org (GovCloud) | Dedicated government infrastructure required |
| Acquired company, shared customers | Merge orgs (12-18 months) | Data unification outweighs integration cost |
| Acquired company, zero shared data | Keep separate | Integration cost exceeds benefit |
| Release cadence conflict (daily vs quarterly) | Evaluate packaging first | Unlocked packages + sandboxes may isolate |
| Governor limits exhausted (50M+ records per BU) | Evaluate multi-org | Each org gets full limit allocation |
The one-way door
Splitting one org into two is painful but achievable. Merging two orgs into one is one of the most expensive projects in the Salesforce ecosystem — typically 12-18 months, millions in cost. Always bias single-org and document why multi-org is unavoidable.
Quick Decision Flowchart
flowchart TD
A[How many orgs?] --> B{Shared customers<br/>or data?}
B -->|Yes| C{Hard data<br/>residency?}
B -->|No shared data| D{Common governance?}
C -->|Hyperforce solves it| E[Single Org]
C -->|Hyperforce cannot| F[Multi-Org]
D -->|Yes| E
D -->|No| G[Separate Orgs]
F --> H{Cross-org<br/>visibility?}
H -->|Yes| I[Multi-Org +<br/>Integration Layer]
H -->|No| J[Loosely Coupled]
style E fill:#2d6a4f,color:#fff
style F fill:#9d0208,color:#fff
style G fill:#e9c46a,color:#000
Hyperforce Cheat Sheet
| What Hyperforce Does | What It Does NOT Do |
|---|---|
| Data residency (at-rest storage in specific AWS regions) | Guarantee all processing stays in-region |
| Deploy closer to users for performance | Prevent email routing through non-local infra |
| Regional compliance alignment | Guarantee Einstein AI processes locally |
| Granular geographic control | Control AppExchange package data locations |
| Same Salesforce features, different infra | Solve MuleSoft/Heroku deployment regions |
Board tip
When a scenario mentions “GDPR” or “data residency,” always evaluate Hyperforce first. If Hyperforce satisfies the requirement, you avoid multi-org complexity. State explicitly: “Hyperforce provides data residency in the EU region, avoiding the need for a separate org.”
Cross-Org Data Sharing Patterns
When multi-org is unavoidable, pick the right integration approach:
| Pattern | Latency | Volume | Cost | Best For |
|---|---|---|---|---|
| Salesforce Connect | On-demand | Any (query) | Included | Read-only cross-org visibility |
| Salesforce-to-Salesforce | Near-real-time | Low | Included | Simple record sharing, 2 orgs |
| Platform Events + CDC | Near-real-time | Medium | Included | Event-driven notifications |
| MuleSoft | Configurable | High | $$$ | Complex multi-system orchestration |
| Heroku Connect | Bidirectional sync | Medium-High | $$ | Postgres-mediated sync |
| Custom API | Configurable | Any | Dev cost | Full control, unique requirements |
Multi-Org Architecture Patterns
| Pattern | Description | Best For |
|---|---|---|
| Hub-and-spoke | One master org, satellites sync to hub | Corporate HQ + regional divisions |
| Peer-to-peer | Orgs communicate directly | 2-3 orgs with limited sharing |
| Federated | Autonomous orgs, shared integration layer | Independent BUs, occasional data sharing |
Peer-to-peer does not scale
Peer-to-peer creates N*(N-1)/2 integration combinations. With 4 orgs, that is 6 integration paths. With 6 orgs, that is 15. Always use hub-and-spoke or federated for more than 3 orgs.
M&A Consolidation Quick Guide
| Factor | Merge | Keep Separate | Connect |
|---|---|---|---|
| Shared customers | Strong merge signal | — | Messy |
| Different industries | — | Likely | If needed |
| Timeline pressure | 12-18+ months | Immediate | 3-6 months |
| Regulatory separation | — | Required | Carefully |
Coexistence is not optional. Even when merging, build temporary integrations for the 6-18 month interim. Budget for this throwaway work.
Edition Selection Quick Ref
| Need | Enterprise | Unlimited | Performance |
|---|---|---|---|
| Custom objects | 200 | 2,000 | 2,000 |
| Storage/user (data) | 20 MB | 120 MB | 120 MB |
| Storage/user (file) | 612 MB | 2 GB | 2 GB |
| Dev sandboxes | 25 | 100 | 100 |
| Premier Support | Add-on | Included | Included |
| Shield | Add-on | Add-on | Included |
| Einstein features | Add-on | Some included | More included |
Cost-awareness wins points
If the scenario needs Shield encryption, note that Performance edition includes it — avoiding a separate Shield purchase. Judges appreciate this level of cost awareness.
Reverse-Engineered Use Cases
Scenario 1: Global manufacturer with EU and US operations, shared customer base, GDPR compliance required.
- Decision: Single-org on Hyperforce (EU region)
- Why: Shared customers demand 360-degree view. Hyperforce satisfies GDPR data residency. Multi-org would require constant cross-org sync of shared accounts.
- Trade-off: Must audit full data flow (email, Einstein, integrations) to ensure no data leakage outside EU.
Scenario 2: Holding company acquires SaaS startup. Startup deploys daily, parent deploys quarterly. Zero shared customers.
- Decision: Keep separate orgs (not multi-org — just independent)
- Why: No shared data means no integration benefit. Release cadence conflict is irreconcilable. Forcing into one org provides no value and creates friction.
- Trade-off: No consolidated reporting. Accept this; there is no shared reporting need.
Scenario 3: Financial services firm needs FedRAMP High for government contracts, but commercial division also uses Salesforce.
- Decision: Multi-org. Government Cloud for federal. Commercial cloud for commercial.
- Why: FedRAMP High requires dedicated government infrastructure. Cannot be solved by Hyperforce or sharing rules.
- Trade-off: Must build integration layer for any shared reference data (products, pricing). Use MuleSoft or Salesforce Connect for read-only visibility.