Org Strategy

Org strategy is a high-impact system architecture decision. It shapes every subsequent choice: security boundaries, data visibility, integration complexity, licensing costs, and operational overhead. Reversing it after the fact carries significant cost and risk.

Single-Org vs Multi-Org

Default to single-org unless there is a compelling, irreversible reason to split. Multi-org adds real 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

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.

CTA Exam Relevance

The board expects you to default to single-org and articulate the specific forcing function that makes multi-org necessary. Candidates who propose multi-org without exhausting single-org solutions (permission sets, sharing rules, packaging, Hyperforce) lose points. When defending single-org, quantify the cost of the alternative: “Multi-org would require N integration connections, duplicate identity management, and cross-org reporting - adding 6+ months and significant ongoing operational cost.”

Decision Flowchart

Figure 1. Core org strategy decision flow enforcing single-org as the default. Hyperforce data residency resolves many regulatory objections without requiring org separation, and release cadence conflicts can often be contained by packaging and sandbox strategies before multi-org becomes the conclusion.

Hyperforce and Data Residency

Hyperforce is Salesforce’s re-architecture onto public cloud infrastructure (AWS and GCP as confirmed substrates), enabling deployment in specific geographic regions. A separate offering on Alibaba Cloud serves the China market. This matters most for data residency requirements.

Hyperforce Architecture

Figure 2. Hyperforce layered architecture showing how Operating Zones enforce regional data governance boundaries, with Hyperforce Instances mapping to public cloud regions and Supercells defining blast radius boundaries between groups of customer org cells. This nesting is what enables granular data residency commitments per geographic region.

The architecture is layered. 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, which are clusters of services delivering specific capabilities. Within Functional Domains, Cells (equivalent to traditional Salesforce instances) host customer orgs. 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 and GCP confirmed substrates)
Data residency	Limited to available data center locations	Multiple global 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, cloud-native services) 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. Whether 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

Figure 3. Org consolidation phasing showing the 12–18 month program structure. Coexistence strategy runs concurrently with the entire migration. Users in both orgs must keep working while the consolidation progresses, which means temporary integrations between orgs are a required investment, not optional overhead.

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.

CTA Exam Relevance

M&A scenarios appear frequently on the CTA board. The board probes whether you considered the coexistence phase - not just the end state. Candidates who jump straight to “we merge the orgs” without addressing how users operate during the 12-18 month transition lose credibility. Present a phased plan: Day 1 coexistence strategy, interim integration layer, data mapping and migration, and final cutover.

Consolidation Decision Flowchart

Figure 4. M&A org decision flow distinguishing between full merge, middleware integration, and keeping orgs separate. Data model alignment within six months is the key gate for a full merge recommendation; when that is not feasible, an integration layer with coexistence is the practical path regardless of the eventual end state.

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 (retiring - avoid for new implementations)	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 (Heroku Enterprise end-of-sale Feb 2026 - sustaining engineering model, new contracts no longer offered; prefer MuleSoft or Data Cloud for new designs)
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. 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 using a publisher/subscriber model.

S2S is being retired

Salesforce-to-Salesforce is scheduled for retirement. For new implementations, use Salesforce Connect, Platform Events, MuleSoft, or custom API integration instead. Existing S2S implementations should plan migration to an alternative cross-org data sharing pattern.

When to use: Only for existing implementations that have not yet migrated to an alternative pattern.

When to avoid: All new implementations. Use Salesforce Connect, Platform Events, or MuleSoft instead.

Government Cloud and Specialized Environments

Government Cloud (GovCloud)

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 needs to define 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.

Figure 5. Hub-and-spoke multi-org topology with a central MuleSoft integration layer. The hub org owns master data and pushes records to each spoke; spokes publish change events back through the middleware for hub aggregation. This pattern scales linearly: adding a spoke adds one integration connection, not N*(N-1)/2.

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.

Figure 6. Peer-to-peer topology with three orgs producing three direct integration connections. This pattern is manageable at two or three orgs but becomes untenable beyond that. Five orgs would require ten connections, and ten orgs would require 45, which is why peer-to-peer should not be proposed for anything beyond a small org count.

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.

CTA Exam Relevance

The board tests multi-org topology knowledge by probing scalability and governance. Know the N*(N-1)/2 formula and cite it when dismissing peer-to-peer for more than 3 orgs. When proposing federated architecture, articulate why the middleware layer (MuleSoft) is worth the cost: “It decouples org changes from each other - a data model change in Org A does not cascade into Org B because the system API absorbs the change.”

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 sharing is needed.

Figure 7. Federated multi-org topology using MuleSoft API-led connectivity. Each autonomous org connects only to System APIs, which absorbs data model changes and prevents them from cascading to other orgs. Experience APIs aggregate data for enterprise reporting without requiring any org to expose its internals directly.

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; changes in one org do not cascade into another.

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

Edition selection 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 + 2 GB/user	10 GB + 2 GB/user	10 GB + 2 GB/user
Full sandboxes	1	1	1
Partial copy sandboxes	1	1	1
Developer Pro sandboxes	1	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. 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, which is critical for LDV scenarios
• Sandboxes: Enterprise’s single full sandbox can bottleneck 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

A systematic approach for determining org strategy when presented with a CTA scenario:

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 the initial estimate.

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