Skip to content
SF CTA Study Hub

Decision Guides

This page collects 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 systematically arrive at an architecture recommendation.

How to use these guides

Do not memorize the flowcharts. Understand the logic behind each decision node. On the CTA exam, you will not have access to these diagrams — but if you understand the reasoning, you can reconstruct the decision process for any scenario.

Single-Org vs Multi-Org

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

flowchart TD
    A[Org Strategy Decision] --> B{Shared customers<br/>or accounts across<br/>business units?}

    B -->|Yes| C{Hard regulatory<br/>data residency<br/>requirement?}
    B -->|No| D{Any shared<br/>data at all?}

    C -->|Yes| E{Can Hyperforce<br/>data residency<br/>satisfy the requirement?}
    C -->|No| F{Irreconcilable<br/>release cadence<br/>conflict?}

    E -->|Yes| G["Single Org<br/>(Hyperforce)"]
    E -->|No| H["Multi-Org Required<br/>(Regulatory)"]

    F -->|Yes| I{Can unlocked packages<br/>+ sandboxes provide<br/>sufficient isolation?}
    F -->|No| J[Single Org]

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

    D -->|Some shared data| C
    D -->|Zero shared data| K{Common governance<br/>and admin team?}

    K -->|Yes| J
    K -->|No| L["Separate Independent Orgs<br/>(Not multi-org — just separate)"]

    H --> M{Cross-org data<br/>visibility needed?}
    M -->|Yes| N["Multi-Org +<br/>Integration Layer<br/>(MuleSoft, S2S, or Connect)"]
    M -->|No| O["Multi-Org<br/>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

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

See Org Strategy for full details.

Org Consolidation (M&A)

After a merger or acquisition, decide whether to merge orgs, keep them separate, or integrate via middleware.

flowchart TD
    A["M&A Org Decision"] --> B{"Significant shared<br/>customers or accounts?"}

    B -->|"Yes"| C{"Data models<br/>alignable within<br/>6 months?"}
    B -->|"No"| D{"Shared sales<br/>teams or processes?"}

    C -->|"Yes"| E["Full Org Merge<br/>(12-18 month program)"]
    C -->|"No, fundamentally different"| F["Integrate via<br/>Middleware Layer"]

    D -->|"Yes"| C
    D -->|"No"| G{"Business justification<br/>to consolidate?<br/>(cost, reporting)"}

    G -->|"Yes"| H{"Regulatory or<br/>edition blockers?"}
    G -->|"No"| I["Keep Separate"]

    H -->|"Yes"| F
    H -->|"No"| J{"12-18 month<br/>timeline feasible?"}

    J -->|"Yes"| E
    J -->|"No"| K["Integrate Now<br/>Merge Later"]

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

Key signals for full merge: Significant customer overlap, shared sales teams, desire for unified reporting, and executive mandate to operate as one business. Key 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.

flowchart TD
    A[Capability Assessment] --> B{Who are the<br/>primary users?}

    B -->|Salesforce users| C{Can the requirement<br/>be met within<br/>governor limits?}
    B -->|Non-Salesforce users| D{Does the capability<br/>need Salesforce data?}

    C -->|Yes, synchronous| E{Declarative<br/>solution possible?}
    C -->|Yes, with async| F["On-Platform<br/>Async Apex"]
    C -->|No| G["Off-Platform<br/>+ Salesforce API"]

    E -->|Yes| H["On-Platform<br/>Declarative (Flows)"]
    E -->|No, needs code| I["On-Platform<br/>Apex + LWC"]

    D -->|Yes, read/write| J["Off-Platform App<br/>+ Salesforce API"]
    D -->|No| K["Fully Off-Platform<br/>(No Salesforce integration)"]

    G --> L{What type of<br/>off-platform need?}
    L -->|Heavy compute or ML| M[Heroku / AWS / GCP]
    L -->|Complex integration| N[MuleSoft]
    L -->|Custom UI| O[Custom Web App<br/>+ Salesforce API]
    L -->|Bulk data processing| P[ETL / Data Pipeline]

    style H fill:#2d6a4f,color:#fff
    style I fill:#2d6a4f,color:#fff
    style F fill:#457b9d,color:#fff
    style G fill:#9d0208,color:#fff
    style J fill:#9d0208,color:#fff
    style K fill:#e9c46a,color:#000

Key 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

Start with the simplest option that meets requirements.

flowchart TD
    A[Mobile Requirement] --> B{Internal or<br/>external users?}

    B -->|Internal| C{Standard Salesforce<br/>Mobile sufficient?}
    B -->|External| D{Need native<br/>app store presence?}

    C -->|Yes| E{Need custom<br/>branding?}
    C -->|No| F{What is the gap?}

    E -->|No| G["Salesforce Mobile App<br/>(Zero cost)"]
    E -->|Yes| H["Mobile Publisher<br/>for Salesforce"]

    F -->|Complex offline + sync| I["Mobile SDK<br/>(Custom development)"]
    F -->|Native device APIs| I
    F -->|Complete UI control| I

    D -->|No| J{Offline<br/>required?}
    D -->|Yes| K{Complex offline<br/>with sync?}

    J -->|No| L["PWA on<br/>Experience Cloud"]
    J -->|Basic caching| L
    J -->|Full offline + sync| I

    K -->|Yes| I
    K -->|No, just branding| M["Mobile Publisher<br/>for Experience Cloud"]

    style G fill:#2d6a4f,color:#fff
    style H fill:#457b9d,color:#fff
    style L fill:#457b9d,color:#fff
    style M fill:#457b9d,color:#fff
    style I fill:#9d0208,color:#fff

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

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

See Mobile Strategy for full details.

Reporting Tool Selection

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

flowchart TD
    A[Reporting Need] --> B{Data source?}

    B -->|Salesforce only| C{Report complexity?}
    B -->|Multi-source<br/>including non-SF| D{Who consumes<br/>the reports?}

    C -->|"Simple: counts, sums,<br/>groupings, filters"| E["Standard Reports<br/>& Dashboards"]
    C -->|"Medium: cross-object joins,<br/>trending, custom calcs"| F{More than 4-object<br/>join needed?}
    C -->|"Complex: predictive,<br/>AI-powered"| G["CRM Analytics +<br/>Einstein Discovery"]

    F -->|No| E
    F -->|Yes| H["CRM Analytics<br/>(Dataflows)"]

    D -->|Salesforce users| I{Unified customer<br/>profile needed?}
    D -->|Non-Salesforce users| J[Tableau]
    D -->|Both| K{Enterprise BI<br/>governance needed?}

    I -->|Yes| L["Data Cloud +<br/>CRM Analytics"]
    I -->|No| H

    K -->|Yes| J
    K -->|No| H

    style E fill:#2d6a4f,color:#fff
    style G fill:#457b9d,color:#fff
    style H fill:#457b9d,color:#fff
    style J fill:#9d0208,color:#fff
    style L fill:#e9c46a,color:#000

Key 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 dashboard limitations (2,000-row limit).

See Reporting & Analytics for full comparison.

Document Management

Evaluate storage, collaboration, and generation needs separately.

flowchart TD
    A[Document Requirement] --> B{Primary need?}

    B -->|File storage| C{Volume over<br/>3-year projection?}
    B -->|Knowledge base| D{Who consumes?}
    B -->|Document generation| E{Template complexity?}
    B -->|E-signature| F{Volume and<br/>complexity?}

    C -->|Within SF limits| G{Need collaborative<br/>editing?}
    C -->|Exceeds limits| H{Existing DMS?}

    G -->|No| I[Salesforce Files]
    G -->|Yes| J["External DMS +<br/>Files Connect"]

    H -->|Yes| J
    H -->|No| K["Evaluate new DMS<br/>vs additional SF storage"]

    D -->|Service agents| L[Salesforce Knowledge]
    D -->|Customer self-service| M{Also need agent-facing?}
    D -->|Marketing / multi-channel| N[External CMS]

    M -->|Yes| L
    M -->|No| O["Experience Cloud CMS<br/>or Knowledge"]

    E -->|Simple merge fields| P[Native Email Templates<br/>/ Quote PDF]
    E -->|Complex logic,<br/>conditionals, tables| Q["Third-Party<br/>(Conga, S-Docs)"]

    F -->|Low volume, simple| R[Salesforce E-Signature]
    F -->|High volume, complex routing| S["DocuSign or<br/>Adobe Sign"]

    style I fill:#2d6a4f,color:#fff
    style L fill:#2d6a4f,color:#fff
    style P fill:#2d6a4f,color:#fff
    style R fill:#2d6a4f,color:#fff
    style J fill:#457b9d,color:#fff
    style Q fill:#9d0208,color:#fff
    style S fill:#9d0208,color:#fff

Key signals for external DMS: Heavy document collaboration (co-authoring), large file volumes exceeding Salesforce storage economics, advanced compliance requirements (DLP, retention, legal holds), or significant non-Salesforce user base.

See Document Management for full details.

License Type Selection

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

flowchart TD
    A[New User] --> B{Internal or<br/>External?}

    B -->|Internal| C{What data<br/>do they need?}
    B -->|External| D{What access<br/>do they need?}

    C -->|Chatter only| E["Chatter Free<br/>($0)"]
    C -->|Authentication only| F[Identity License]
    C -->|Custom app, no CRM objects| G{App complexity?}
    C -->|CRM objects<br/>Opps, Cases, etc.| H{Which cloud?}

    G -->|"1 app, ≤10 objects"| I[Platform Starter]
    G -->|"Multiple apps,<br/>more objects"| J[Platform Plus]

    H -->|Sales| K[Sales Cloud]
    H -->|Service| L[Service Cloud]
    H -->|Both| M[Sales + Service]

    D -->|Self-service portal<br/>No sharing needs| N["Customer Community<br/>(cheapest)"]
    D -->|Portal with sharing rules<br/>and role hierarchy| O[Customer Community Plus]
    D -->|Partner deal<br/>registration| P[Partner Community]
    D -->|API or custom<br/>app only| Q[External Apps]
    D -->|Authentication only| R[External Identity]

    N --> S{Usage frequency?}
    O --> S
    P --> S
    Q --> S

    S -->|"Daily/weekly"| T[Member-based pricing]
    S -->|"Monthly or less"| U[Login-based pricing]

    style E fill:#2d6a4f,color:#fff
    style I fill:#2d6a4f,color:#fff
    style N fill:#2d6a4f,color:#fff
    style R fill:#2d6a4f,color:#fff

Key decision points: Does the user need standard CRM objects (Opportunities, Cases)? If no, Platform licenses save significant cost. For external users, does the portal need role-based sharing? If no, 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.

flowchart TD
    A[Async Processing Needed] --> B{Data volume?}

    B -->|"Small (single record<br/>or small set)"| C{Need to pass<br/>complex data?}
    B -->|"Large (thousands<br/>to millions)"| D[Batch Apex]

    C -->|"No, just IDs<br/>or primitives"| E{Need to chain<br/>multiple steps?}
    C -->|"Yes, complex objects"| F[Queueable Apex]

    E -->|No| G[Future Method]
    E -->|Yes| F

    D --> H{Need scheduled<br/>execution?}
    F --> H

    H -->|Yes| I[Schedulable Apex<br/>invokes Batch or Queueable]
    H -->|No| J[Execute directly]

    style G fill:#2d6a4f,color:#fff
    style F fill:#457b9d,color:#fff
    style D fill:#9d0208,color:#fff
    style I fill:#e9c46a,color:#000

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.

flowchart TD
    A[Cross-Org Data Need] --> B{Direction of<br/>data flow?}

    B -->|"Read-only visibility<br/>from Org B in Org A"| C{Data volume<br/>per query?}
    B -->|"Bidirectional sync"| D{Complexity of<br/>transformations?}
    B -->|"One-way push<br/>from Org A to Org B"| E{Frequency?}

    C -->|Low-Medium| F["Salesforce Connect<br/>(External Objects)"]
    C -->|High or<br/>complex queries| G["MuleSoft or<br/>Custom Integration"]

    D -->|"Simple (field mapping)"| H["Salesforce-to-Salesforce<br/>(if 2 orgs, simple objects)"]
    D -->|"Complex (logic, routing)"| G

    E -->|Real-time| I["Platform Events<br/>+ Subscriber"]
    E -->|Near-real-time batch| J["Heroku Connect<br/>or Change Data Capture"]
    E -->|Scheduled batch| K["MuleSoft or<br/>Custom Batch"]

    style F fill:#2d6a4f,color:#fff
    style H fill:#2d6a4f,color:#fff
    style I fill:#457b9d,color:#fff
    style G fill:#9d0208,color:#fff

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

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

Sources