Org Strategy

Org strategy is the single most consequential system architecture decision a CTA makes. It determines the blast radius of every subsequent choice — security boundaries, data visibility, integration complexity, licensing costs, and operational overhead. Getting it wrong is extraordinarily expensive to reverse.

Single-Org vs Multi-Org

The default should always be single-org unless there is a compelling, irreversible reason to split. Multi-org adds exponential complexity to integration, identity, reporting, and governance.

Single-Org Advantages

Advantage	Why It Matters
Unified data model	360-degree view of customers, accounts, opportunities without integration
Single identity	One login, one permission model, one sharing architecture
Native reporting	Cross-functional reports and dashboards without ETL
Lower total cost	One set of licenses, one admin team, one release cycle
Simpler governance	One metadata deployment pipeline, one sandbox strategy
Platform limits pool	Governor limits are per-org, so a single org gets the full allocation

Multi-Org Drivers

These are the scenarios where multi-org becomes necessary or strongly advisable:

Driver	Example	Why Single-Org Fails
Regulatory isolation	GDPR data residency requiring EU-only processing	Data must not leave a jurisdiction; sharing rules cannot enforce this
Extreme release cadence conflict	Acquired startup deploys daily; parent deploys quarterly	Sandbox and release strategies are fundamentally incompatible
Security boundary requirements	Government classified vs. commercial operations	FedRAMP/IL4+ requires dedicated infrastructure
Unrelated business units	Conglomerate with zero shared customers or data	Shared org adds complexity with no data benefit
Governor limit exhaustion	Two business units each need 50M+ records	LDV strategies may be insufficient within a single org
M&A with long-term independence	Acquired company retains brand, operations, and CRM independently	Integration cost exceeds benefit when businesses remain separate

Multi-org is a one-way door

Splitting into multiple orgs is relatively straightforward. Merging orgs back together is one of the most painful and expensive projects in the Salesforce ecosystem. Always bias toward single-org and document specifically why multi-org is unavoidable.

Decision Flowchart

flowchart TD
    A[Start: How many orgs?] --> B{Shared customers<br/>or accounts?}
    B -->|Yes| C{Regulatory data<br/>residency requirement?}
    B -->|No| D{Any shared data<br/>at all?}

    C -->|Yes, hard requirement| E{Can Hyperforce<br/>data residency solve it?}
    C -->|No| F{Release cadence<br/>conflict?}

    E -->|Yes| G[Single Org on Hyperforce]
    E -->|No| H[Multi-Org Required]

    F -->|Irreconcilable| I{Can sandboxes +<br/>unlocked packages isolate?}
    F -->|Manageable| J[Single Org]

    I -->|Yes| J
    I -->|No| H

    D -->|Yes| C
    D -->|No| K{Governance<br/>alignment?}

    K -->|Aligned| J
    K -->|Completely independent| L[Separate Orgs<br/>Not multi-org — just separate]

    H --> M{Need cross-org<br/>data visibility?}
    M -->|Yes| N[Multi-Org + Integration Layer]
    M -->|No| O[Multi-Org, Loosely Coupled]

    style G fill:#2d6a4f,color:#fff
    style J fill:#2d6a4f,color:#fff
    style H fill:#9d0208,color:#fff
    style L fill:#e9c46a,color:#000
    style N fill:#9d0208,color:#fff
    style O fill:#e9c46a,color:#000

Hyperforce and Data Residency

Hyperforce is Salesforce’s re-architecture onto public cloud infrastructure (primarily AWS and GCP as confirmed substrates), enabling deployment in specific geographic regions. This is critical for data residency requirements.

Hyperforce Architecture

flowchart TD
    subgraph OZ["Operating Zone (e.g., EU OZ)"]
        subgraph HI["Hyperforce Instance (AWS Region)"]
            subgraph FD["Functional Domain"]
                subgraph SC["Supercell"]
                    C1["Cell A<br/>(SF Instance)"]
                    C2["Cell B<br/>(SF Instance)"]
                end
            end
            FD2["Foundational Domain<br/>Security, Auth, Logging,<br/>Monitoring"]
        end
    end

    subgraph CS["Customer Orgs"]
        O1["Org 1"] --> C1
        O2["Org 2"] --> C1
        O3["Org 3"] --> C2
    end

    subgraph PC["Public Cloud Infrastructure"]
        AZ1["Availability Zone 1"]
        AZ2["Availability Zone 2"]
        AZ3["Availability Zone 3"]
    end

    HI --> AZ1
    HI --> AZ2
    HI --> AZ3

    style OZ fill:#1b4332,color:#fff
    style HI fill:#2d6a4f,color:#fff
    style FD fill:#40916c,color:#fff
    style SC fill:#52b788,color:#000
    style FD2 fill:#457b9d,color:#fff
    style PC fill:#e9c46a,color:#000

The architecture is organized in layers: Operating Zones group Hyperforce Instances under unified governance rules (e.g., EU OZ for enhanced data residency). Hyperforce Instances map to public cloud regions and contain Functional Domains — clusters of services delivering specific capabilities. Within Functional Domains, Cells (equivalent to traditional Salesforce instances) host customer orgs, and Supercells group cells that share certain services, defining the blast radius boundary.

What Hyperforce Changes

Aspect	Classic Infrastructure	Hyperforce
Deployment location	Salesforce-managed data centers	Public cloud regions (AWS, GCP confirmed; Azure not confirmed as substrate)
Data residency	Limited to available data center locations	38+ regions with granular geographic control
Compliance	Depends on data center certifications	Regional compliance alignment + Operating Zones
Performance	Fixed to data center proximity	Deploy closer to users
Scaling	Vertical (bigger servers)	Horizontal (more cells across availability zones)
Backup location	Same region as primary	Same region, multi-AZ redundancy
Cost to customer	Standard pricing	No additional cost for Hyperforce infrastructure

What Hyperforce Does NOT Solve

Common misconception

Hyperforce provides data residency (where data is stored and processed at rest), but it does not prevent data from crossing borders during processing in all scenarios. Evaluate carefully:

• Email services may route through non-local infrastructure
• Einstein AI features may process data in specific regions only
• AppExchange packages may have their own data processing locations
• Integration middleware (MuleSoft, Heroku) has its own deployment regions

Data Residency Decision Framework

1. Identify regulatory requirements — GDPR, LGPD, PIPL, POPIA, or industry-specific
2. Map data classification — What data is subject to residency requirements?
3. Evaluate Hyperforce availability — Is the required region available?
4. Audit the full data flow — Including integrations, email, AI, and AppExchange
5. Document exceptions — What data legitimately crosses borders (with legal approval)?

Org Consolidation After M&A

Merging Salesforce orgs after a merger or acquisition is among the most complex programs an architect designs. The decision to merge vs. keep separate is itself a major architectural call.

Consolidation Decision Matrix

Factor	Merge Orgs	Keep Separate	Connect via Integration
Shared customers	Strong signal to merge	—	Possible but messy
Shared sales teams	Strong signal to merge	—	—
Different industries	—	Consider keeping separate	Connect if needed
Different editions	Evaluate cost of upgrade	Keep if cost-prohibitive	Connect
Regulatory separation	—	Required	Connect carefully
Timeline pressure	12-18+ months typical	Immediate	3-6 months

Consolidation Phases

flowchart LR
    A[Discovery &<br/>Assessment] --> B[Coexistence<br/>Strategy]
    B --> C[Data Migration<br/>& Mapping]
    C --> D[Metadata<br/>Alignment]
    D --> E[Cutover &<br/>Validation]
    E --> F[Decommission<br/>Source Org]

    A -.->|"4-8 weeks"| B
    B -.->|"Ongoing"| C
    C -.->|"8-16 weeks"| D
    D -.->|"4-8 weeks"| E
    E -.->|"2-4 weeks"| F

Coexistence is not optional

Even if you plan to merge, you need a coexistence strategy for the interim. Users in both orgs need to work during the 6-18 month consolidation. This often means building temporary integrations that you will decommission — budget for this throwaway work.

Consolidation Decision Flowchart

flowchart TD
    A["M&A: Merge Orgs<br/>or Keep Separate?"] --> B{"Shared customers<br/>or accounts?"}

    B -->|"Yes, significant overlap"| C{"Can you align<br/>data models?"}
    B -->|"No overlap"| D{"Shared sales<br/>teams?"}

    C -->|"Yes, within 6 months"| E["Merge Orgs"]
    C -->|"No, fundamentally different"| F["Integrate via<br/>Middleware"]

    D -->|"Yes"| C
    D -->|"No"| G{"Any business reason<br/>to consolidate?"}

    G -->|"Cost savings, unified reporting"| H{"Regulatory or<br/>edition blockers?"}
    G -->|"No"| I["Keep Separate"]

    H -->|"Yes"| F
    H -->|"No"| J{"Timeline<br/>feasible?"}

    J -->|"12-18 months OK"| E
    J -->|"Need it faster"| K["Integrate Now,<br/>Merge Later"]

    E --> L["Full Consolidation<br/>12-18 month program"]
    F --> M["Coexistence +<br/>Integration Layer"]
    K --> M

    style E fill:#2d6a4f,color:#fff
    style I fill:#e9c46a,color:#000
    style F fill:#457b9d,color:#fff
    style K fill:#457b9d,color:#fff
    style L fill:#2d6a4f,color:#fff
    style M fill:#457b9d,color:#fff

Key Consolidation Risks

• Data conflicts: Duplicate accounts, contacts, opportunities with different schemas
• Automation conflicts: Workflows, flows, triggers that assume different data models
• User resistance: Teams attached to their existing processes and customizations
• License gaps: Source org may have features/licenses the target org lacks
• AppExchange dependencies: Managed packages that cannot be easily migrated
• Historical data: Decision on what history to migrate vs. archive

Cross-Org Data Sharing Options

When you have multiple orgs (by choice or necessity), you need patterns for sharing data between them.

Option Comparison

Option	Latency	Data Volume	Complexity	Cost	Best For
Salesforce Connect (External Objects)	Real-time (on-demand)	Any (query-based)	Low-Medium	Included with some editions	Read-heavy cross-org visibility
Salesforce-to-Salesforce	Near real-time	Low-Medium	Low	Included	Simple record sharing between orgs
MuleSoft	Configurable	High	High	Significant license cost	Complex multi-system orchestration
Heroku Connect	Near real-time (bidirectional sync)	Medium-High	Medium	Heroku + Connect licensing	Postgres-mediated data sync
Platform Events	Near real-time	Medium	Medium	Included (with limits)	Event-driven cross-org notifications
Custom API Integration	Configurable	Any	High	Development cost	Full control, unique requirements

Salesforce Connect (External Objects)

Salesforce Connect uses OData or cross-org adapters to expose external data as read-only (or limited write) objects in Salesforce. The data is not copied — it is queried on demand.

When to use: You need visibility into another org’s data but do not need to own, report on, or trigger automation from that data at scale.

When to avoid: Heavy reporting needs, complex automation triggers, offline access requirements, or when query latency is unacceptable.

Salesforce-to-Salesforce (S2S)

A native feature for sharing records between two Salesforce orgs through a publisher/subscriber model.

When to use: Simple, low-volume record sharing between two Salesforce orgs with straightforward mapping.

When to avoid: High-volume scenarios, complex transformations, more than two orgs, or bidirectional sync with conflict resolution needs.

S2S limitations

Salesforce-to-Salesforce has significant limitations: it only supports standard objects and a subset of custom objects, has limited field mapping, and does not handle complex transformations. For anything beyond simple record sharing, consider MuleSoft or custom integration.

Government Cloud and Specialized Environments

Government Cloud (GovCloud)

Salesforce Government Cloud is available in multiple tiers, each meeting different compliance levels.

Feature	Commercial Cloud	Government Cloud Plus	Government Cloud Plus Defense
Infrastructure	Shared multi-tenant	Dedicated government infrastructure	Dedicated DoD-approved infrastructure
Compliance	SOC 2, ISO 27001	FedRAMP High, DoD IL2	FedRAMP High, DoD IL4/IL5, ITAR
Data residency	US or international	US-only, government-controlled	US-only, defense-controlled
Feature parity	Full feature set	Slight feature lag (features arrive later)	More restricted feature set
AppExchange	Full marketplace	Government-approved packages only	Government-approved packages only
Cost	Standard pricing	Premium pricing	Higher premium pricing

When Government Cloud Plus is required: Federal civilian agencies, state/local governments with FedRAMP High requirements, contractors handling CUI data.

When Government Cloud Plus Defense is required: DoD agencies and defense contractors handling IL4/IL5 classified data and ITAR-controlled information.

When neither is required: Commercial companies selling to government (they may only need compliance certifications, not dedicated infrastructure).

Multi-Org Architecture Patterns

When multi-org is unavoidable, the architecture must address how the orgs relate to each other.

Hub-and-Spoke

One primary org acts as the master data hub. Satellite orgs sync data to and from the hub.

flowchart TD
    subgraph Legend
        direction LR
        L1[🟢 NEW]
        L2[⚪ KEEPING]
        L3[🔴 RETIRING]
        L4[🟠 INTEGRATION LAYER]
    end

    subgraph Integration["Integration Layer"]
        MW["MuleSoft / ESB"]
    end

    A["Hub Org<br/>Master Data"]
    B["Spoke Org 1<br/>Business Unit A"]
    C["Spoke Org 2<br/>Business Unit B"]
    D["Spoke Org 3<br/>Business Unit C"]

    A -->|"Master data push"| MW
    MW -->|"Synced records"| B
    MW -->|"Synced records"| C
    MW -->|"Synced records"| D

    B -->|"Change events"| MW
    C -->|"Change events"| MW
    D -->|"Change events"| MW
    MW -->|"Aggregated updates"| A

    style A fill:#1565c0,color:#fff
    style MW fill:#e65100,color:#fff
    style B fill:#868e96,color:#fff
    style C fill:#868e96,color:#fff
    style D fill:#868e96,color:#fff

Best for: Organizations with a corporate HQ and regional or divisional operations that share core customer data.

Peer-to-Peer

Orgs communicate directly with each other without a central hub.

flowchart TD
    subgraph Legend
        direction LR
        L1[🟢 NEW]
        L2[⚪ KEEPING]
        L3[🔴 RETIRING]
        L4[🟠 INTEGRATION LAYER]
    end

    A["Org A<br/>Business Unit 1"]
    B["Org B<br/>Business Unit 2"]
    C["Org C<br/>Business Unit 3"]

    A <-->|"Direct API / S2S<br/>Account & Contact sync"| B
    B <-->|"Direct API / S2S<br/>Order data"| C
    A <-->|"Direct API / S2S<br/>Reporting data"| C

    style A fill:#1565c0,color:#fff
    style B fill:#1565c0,color:#fff
    style C fill:#1565c0,color:#fff

Best for: Small number of orgs (2-3) with limited data sharing needs. Becomes unmanageable beyond 3-4 orgs due to N*(N-1)/2 integration combinations.

Peer-to-peer scaling problem

With 3 orgs you have 3 integration connections. With 5 orgs you have 10. With 10 orgs you have 45. The formula is N*(N-1)/2. Beyond 3 orgs, migrate to hub-and-spoke or federated to avoid integration sprawl.

Federated

Each org is autonomous with its own data model and processes. A shared integration layer (typically MuleSoft) provides API-mediated access when cross-org data is needed.

flowchart TD
    subgraph Legend
        direction LR
        L1[🟢 NEW]
        L2[⚪ KEEPING]
        L3[🔴 RETIRING]
        L4[🟠 INTEGRATION LAYER]
    end

    subgraph IL["Integration Layer — MuleSoft Anypoint"]
        API["Experience APIs"]
        PROC["Process APIs"]
        SYS["System APIs"]
        SYS --> PROC --> API
    end

    A["Org A<br/>Autonomous BU"]
    B["Org B<br/>Autonomous BU"]
    C["Org C<br/>Autonomous BU"]
    D["External Systems<br/>ERP, DW, etc."]
    E["Enterprise Reporting /<br/>Data Warehouse"]

    A <-->|"REST / Events"| SYS
    B <-->|"REST / Events"| SYS
    C <-->|"REST / Events"| SYS
    D <-->|"SOAP / JDBC"| SYS
    API -->|"Aggregated data feeds"| E

    style IL fill:#e65100,color:#fff
    style API fill:#e65100,color:#fff
    style PROC fill:#e65100,color:#fff
    style SYS fill:#e65100,color:#fff
    style A fill:#1565c0,color:#fff
    style B fill:#1565c0,color:#fff
    style C fill:#1565c0,color:#fff
    style D fill:#868e96,color:#fff
    style E fill:#868e96,color:#fff

Best for: Large organizations with truly independent business units that occasionally need to share data for enterprise reporting or cross-sell. The integration layer decouples orgs from each other — org changes do not cascade.

Multi-Org Topology Comparison

Factor	Hub-and-Spoke	Peer-to-Peer	Federated
Complexity	Medium	Low (few orgs) / Very High (many)	High (but manageable)
Scalability	Good (add spokes)	Poor beyond 3 orgs	Excellent
Master data	Hub owns master data	No clear owner	Each org owns its data
Integration points	N (hub to each spoke)	N*(N-1)/2	N (each org to middleware)
Org independence	Spokes depend on hub	Fully independent	Fully independent
Best org count	3-10 orgs	2-3 orgs	5+ orgs
Identity model	Hub as IdP, spokes as SPs	Independent or shared IdP	Shared IdP (AD/Okta)

Sandbox Strategy in Multi-Org

Org Role	Sandbox Needs	Recommendation
Hub org	Highest complexity; all integration testing	Unlimited edition for full sandboxes
Spoke orgs	Independent testing + integration testing with hub	At minimum Enterprise; consider Unlimited
Testing integration	Must test cross-org integrations	Dedicated sandbox pairs (Hub sandbox A <-> Spoke sandbox A)

Multi-org sandbox coordination

The hardest part of multi-org is testing. You need paired sandboxes — a hub sandbox connected to spoke sandboxes — to test integration flows. Sandbox refreshes must be coordinated across orgs, which adds significant operational overhead.

Edition Differences

Choosing the right Salesforce edition is an architectural decision that affects available features, limits, and costs.

Enterprise vs Unlimited vs Performance

Capability	Enterprise	Unlimited	Performance
Custom objects	200	2,000	2,000
Custom apps	50	Unlimited	Unlimited
API calls (per 24h)	Base + 1,000/user	Base + 5,000/user	Base + 5,000/user
Storage (data)	10 GB + 20 MB/user	10 GB + 120 MB/user	10 GB + 120 MB/user
Storage (file)	10 GB + 612 MB/user	10 GB + 2 GB/user	10 GB + 2 GB/user
Full sandboxes	1	1	1
Partial copy sandboxes	5	5	5
Developer sandboxes	25	100	100
Premier Support	Add-on	Included	Included
Einstein features	Add-on	Some included	More included
Data Cloud	Add-on	Add-on	Some included
Shield	Add-on	Add-on	Included

CTA exam guidance

On the exam, always recommend the edition that meets requirements without over-provisioning. If a customer needs Shield encryption, calling out that Performance edition includes it (vs. purchasing separately) demonstrates cost-awareness that judges appreciate.

Edition Selection Factors

• API volume: Total = base + (per-user allocation x user count). Enterprise gets 1,000 calls/user; Unlimited and Performance get 5,000 calls/user — so a 500-user Unlimited org gets far more API capacity than a 500-user Enterprise org. Additional calls can be purchased separately
• Storage: Unlimited and Performance provide significantly more storage per user — critical for LDV scenarios
• Sandboxes: Enterprise’s single full sandbox can be a bottleneck for complex release strategies
• Support: Unlimited includes Premier Support, which may be required for mission-critical deployments
• Bundled features: Performance bundles Sales + Service + many add-ons at a discount vs. buying separately

Org Strategy Assessment Methodology

When presented with a CTA scenario, use this systematic approach to determine org strategy:

Step 1: Map Business Units

Identify all business units, regions, or divisions mentioned in the scenario. Document their relationships.

Step 2: Identify Shared Data

For each pair of business units, ask: Do they share customers, accounts, products, or any other data? If yes, single-org bias increases.

Step 3: Check Regulatory Constraints

Are there data residency, compliance, or security boundary requirements that prevent data from coexisting in one org? If yes, multi-org may be forced.

Step 4: Evaluate Release Cadence

Can all business units tolerate the same release schedule? If one unit deploys weekly and another quarterly, evaluate whether packaging and sandboxes can provide sufficient isolation.

Step 5: Calculate Total Cost of Ownership

Model the cost of single-org (higher edition, more storage) vs. multi-org (multiple licenses, integration development, operational overhead). Multi-org costs are almost always higher than they appear.

Step 6: Document and Defend

Write down the decision with explicit rationale. Be prepared to defend it with: “I chose [single/multi]-org because [specific reasons from the scenario]. The trade-off I accept is [what you give up], which I mitigate by [how you address it].”

Related Topics

• Licensing — License types constrain and enable org strategy decisions
• Platform Capabilities — Governor limits and multi-tenant constraints affect single vs multi-org
• Decision Guides — Visual decision flowcharts for org strategy
• Trade-Offs — Single vs multi-org trade-off analysis
• Integration — Cross-org data sharing requires integration architecture
• Security — Security boundaries and data classification drive org separation decisions

Sources

• Salesforce Architects: Multi-Org Strategy
• Salesforce Help: Hyperforce
• Salesforce Help: Salesforce Connect
• Salesforce Help: Salesforce-to-Salesforce
• Salesforce Help: Government Cloud
• Salesforce Help: Salesforce Editions Comparison
• Salesforce Architects: Platform Transformation — Hyperforce
• Salesforce Engineering: Behind the Scenes of Hyperforce
• Salesforce Well-Architected: Org Strategy