Decision Guides

The key decision flowcharts for Domain 1: System Architecture. Each flowchart is a visual aid for the CTA exam. When presented with a scenario, use these trees to work through an architecture recommendation step by step.

How to use these guides

Do not memorize the flowcharts. Understand the logic behind each decision node. The diagrams will not be available during the exam, but the reasoning behind them can be reconstructed for any scenario.

Single-Org vs Multi-Org

The scenario will describe business units and their relationships. The first question is always whether they share customer data. If yes, single-org bias is high. If a regulatory requirement like GDPR data residency is present, the next question is whether Hyperforce can satisfy it — not whether multi-org is needed. Hyperforce Operating Zones in EU, APAC, and other regions resolve most geographic residency requirements. The multi-org terminal is only correct when the requirement is truly unsatisfiable by Hyperforce: FedRAMP High, IL4/IL5, contractual isolation beyond geographic residency, or genuinely irreconcilable release cadence conflicts that packaging cannot contain. Common wrong answers: proposing multi-org because “security is important” without citing a specific boundary requirement, or multi-org because business units “want independence” when they share customers.

The default is always single-org. Multi-org requires justification.

Figure 1. Single-org is the default; this flowchart surfaces the specific forcing functions that justify multi-org. Hyperforce data residency resolves many regulatory objections before reaching a multi-org conclusion, and release cadence conflicts can often be absorbed by packaging and sandboxes.

Detailed walkthrough

The first decision node, “Shared customers or accounts across business units?”, is the sharpest cut in the tree. If business units share customer records and need a unified view of that customer’s activity, separate orgs create a data synchronization problem that compounds over time. Shared customers are the single strongest argument for single-org.

The “Yes, shared customers” branch leads immediately to data residency. Many candidates default to multi-org here prematurely. A scenario that says “we need EU data residency for GDPR compliance” does not automatically require a separate org. Hyperforce lets you designate a specific geographic region as the data residency location, keeping EU data in EU data centers. The multi-org terminal on the regulatory branch should only be reached when the requirement is genuinely unsatisfiable by Hyperforce: FedRAMP authorization, IL4/IL5 government cloud requirements, or contractual isolation clauses that go beyond geographic residency.

The release cadence branch is the second most common false positive for multi-org. Business units wanting independent release schedules sometimes request their own org. The correct counter-question is whether unlocked packages plus sandbox environments can provide sufficient isolation. Unlocked packages let a BU own, version, and deploy its components independently without affecting shared components. Multi-org is the answer only when the cadence conflict is genuinely irreconcilable: different release freeze windows, radically different change velocity, or regulatory requirements around change management that cannot coexist.

The “Separate Independent Orgs” terminal on the right is not multi-org. Two orgs belonging to completely separate businesses with no shared customers and no shared administration are just two independent orgs. Multi-org is an intentional pattern where a single enterprise operates multiple connected orgs with an integration layer. When the scenario reaches the multi-org terminal with cross-org visibility required, the architecture needs MuleSoft, Salesforce Connect, or Platform Events to stitch the orgs together. That integration cost is why single-org is the default.

The CTA heuristic: state single-org as your recommendation, then walk through the forcing functions. Name the specific signal in the scenario that overrides the default. If no signal is present, hold single-org.

Signals for multi-org: Regulatory data residency that Hyperforce cannot satisfy, FedRAMP/IL4+ security requirements, business units with zero shared data, or release cadence conflicts that sandboxes and packaging cannot isolate.

See Org Strategy for full details.

---

Org Consolidation (M&A)

After a merger or acquisition: merge orgs, keep them separate, or integrate via middleware.

Figure 2. Post-M&A org strategy turns on whether the acquired company shares customers and whether data models can be reconciled within six months. When timeline pressure prevents a full merge, “integrate now, merge later” is the pragmatic middle path rather than forcing a rushed consolidation.

Signals for full merge: Significant customer overlap, shared sales teams, desire for unified reporting, executive mandate to operate as one business. Signals for integration-only: Different industries, regulatory separation requirements, fundamentally different data models, or near-term timeline pressure.

See Org Strategy for consolidation phases and risks.

---

On-Platform vs Off-Platform

Platform-first is the default. Only go off-platform when you can articulate a specific constraint.

Figure 3. The on-vs-off-platform decision splits first on user type, then on governor limit feasibility. Non-Salesforce users almost always land off-platform; Salesforce users exhaust declarative, synchronous, and async options before any off-platform recommendation is justified.

Signals for off-platform: Transaction exceeds governor limits even with async processing, long-running computation (minutes to hours), complex UI requirements beyond Lightning, heavy data processing or ML model training, IoT or real-time streaming at scale.

See Platform Capabilities & Constraints for governor limits and async patterns.

---

Mobile Strategy Selection

The correct mobile decision starts by separating internal employees from external users. Internal users with no branding requirement get the Salesforce Mobile App. Internal users with branding requirements get Mobile Publisher. For external users, the question is whether they need a native app store presence at all — if not, PWA on Experience Cloud is faster and cheaper. Mobile SDK is justified only when the requirement is one of three things: complex offline data sync with bidirectional conflict resolution, native device hardware integration (Bluetooth, NFC, sensors, AR), or complete custom UI control with no Salesforce chrome. Field Service scenarios follow a different path entirely — always evaluate Field Service Mobile before proposing Mobile SDK for field technicians. Field Service Mobile has strong offline capabilities purpose-built for this use case.

Start with the simplest option that meets the requirements.

Figure 4. Mobile strategy selection starts with user type, then targets the simplest option that meets requirements. Mobile SDK is justified only when standard mobile falls short due to complex offline sync, native device APIs, or full UI control, not simply because custom branding is desired.

Signals for Mobile SDK: Complex offline workflows with bidirectional sync, native device integration (Bluetooth, NFC, sensors), full custom UI, or performance-critical mobile applications.

Do not forget: Field Service has its own mobile app with strong offline support. If the scenario involves field technicians, evaluate Field Service Mobile before reaching for Mobile SDK.

See Mobile Strategy for full details.

---

Reporting Tool Selection

Start every reporting question by asking whether standard reports can answer it. Escalation triggers are specific and should be named explicitly: the four-object join limit, the 2,000-row dashboard cap, the 3-month historical trending ceiling, predictive analytics requirements, or non-Salesforce users who need to consume the data. When the escalation is to CRM Analytics, distinguish between Dataflows (legacy, JSON-based, still needed for advanced augment operations) and Recipes (preferred for new work, visual, supports write-back). When the question involves enterprise BI across multiple systems (ERP, marketing platform, CRM), Tableau plus a central data warehouse is the correct architectural pattern, not forcing everything into CRM Analytics.

Match the tool to the data complexity, user persona, and data source.

Figure 5. Reporting tool escalation follows two tracks: Salesforce-only data routes through complexity tiers to Standard Reports or CRM Analytics; multi-source data routes through user persona to Tableau or Data Cloud. Standard Reports should always be the default unless a specific gap forces escalation.

Signals for escalating beyond standard reports: More than 4-object joins, historical trending beyond 3 months, predictive analytics, multi-source data, non-Salesforce consumers, or the 2,000-row dashboard limit.

See Reporting & Analytics for full comparison.

---

Document Management

Evaluate storage, collaboration, and generation needs as separate concerns.

Figure 6. Document management is four separate architectural decisions (storage, knowledge, generation, and e-signature), each evaluated independently. Collaborative editing and projected 3-year file volume are the most common triggers for recommending an external DMS over native Salesforce Files.

Signals for external DMS: Heavy document collaboration (co-authoring), large file volumes that exceed Salesforce storage economics, advanced compliance requirements (DLP, retention, legal holds), or a large non-Salesforce user base.

See Document Management for full details.

---

License Type Selection

The decision framework starts with the cheapest license that meets the requirement. Does the user need Opportunities, Cases, Campaigns, or Forecasts? If no, Platform licenses apply and can save significant cost. Does the user access Salesforce at all, or just collaborate via Chatter? Chatter Free costs nothing. For external users, the most common mistake is selecting Customer Community Plus when Customer Community is sufficient — the key discriminator is whether the portal needs role-based sharing rules. If users only need to see their own account’s records, Customer Community without role hierarchy is sufficient. For edition selection, calculate whether buying a specific feature as an add-on or PSL is cheaper than upgrading the entire org to the next edition tier.

Always start with the cheapest license that meets the user’s requirements. Upgrade only when necessary.

Figure 7. The most complete license selection flow in Domain 1, combining internal user tiers, external portal license types, and the member vs login pricing split. External users with infrequent logins are often the largest source of licensing overspend when organizations default to member-based pricing.

Decision points: Does the user need standard CRM objects (Opportunities, Cases)? If not, Platform licenses save real money. For external users, does the portal need role-based sharing? If not, Customer Community (not Plus) is sufficient. Always model usage frequency for login vs member pricing.

See Licensing for full license comparison.

---

Async Processing Pattern Selection

When synchronous processing hits governor limits, choose the right async pattern.

Figure 8. Async pattern selection follows two primary branches: large data volume goes directly to Batch Apex; small volume routes through data complexity and chaining needs to Future Method or Queueable. Schedulable Apex is a scheduling wrapper, not a processing pattern in its own right.

See Platform Capabilities & Constraints for async limits and patterns.

---

Cross-Org Data Sharing

When multiple orgs need to share data, select the appropriate integration pattern.

Figure 9. Cross-org data sharing pattern selection separates read-only visibility, bidirectional sync, and one-way push into distinct decision paths. Salesforce Connect works well for low-volume read-only access; Platform Events handle real-time push; MuleSoft becomes the answer when transformation complexity or query volume exceeds simpler options.

See Org Strategy for cross-org sharing options and Integration for integration patterns.

Related Topics

• Trade-Offs: Detailed trade-off analysis for each decision area
• Best Practices: Architectural principles behind these decisions

Sources

• Salesforce Architects: Decision Guides
• Salesforce Architects: Well-Architected Framework
• Salesforce Architects: Multi-Org Strategy
• Salesforce Architects: Mobile Architecture
• Salesforce Architects: Analytics Architecture