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 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
Section titled “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 |
Quick Decision Flowchart
Section titled “Quick Decision Flowchart”Hyperforce Cheat Sheet
Section titled “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/middleware deployment regions |
Cross-Org Data Sharing Patterns
Section titled “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 (retiring — prefer Salesforce Connect cross-org adapter or MuleSoft) | 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 (sustaining engineering model, new contracts no longer offered; prefer MuleSoft/Data Cloud for new designs) |
| Custom API | Configurable | Any | Dev cost | Full control, unique requirements |
Multi-Org Architecture Patterns
Section titled “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 |
M&A Consolidation Quick Guide
Section titled “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, temporary integrations are needed for the 6-18 month interim. Budget for this throwaway work.
Edition Selection Quick Ref
Section titled “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 |
Reverse-Engineered Use Cases
Section titled “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.
Sources
Section titled “Sources”Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.