System Architecture

Key Takeaways

System Architecture is the broadest CTA domain. It covers org strategy, licensing, mobile, reporting, document management, and platform capabilities. Build a strong mental model for on-platform vs off-platform decisions, know governor limits and multi-tenant constraints cold, and be prepared to justify single-org vs multi-org choices at the review board.

This domain tests the ability to design solutions using the right mix of on-platform and off-platform systems while respecting platform capabilities, constraints, and limits. Six objectives span org strategy, licensing, mobile, reporting, document management, and platform capabilities.

Objectives & Study Pages

Each objective maps to one or more dedicated study pages:

1. Single-Org vs Multi-Org Environments

• Org Strategy: Single vs multi-org decision matrix, Hyperforce, data residency, M&A consolidation, cross-org data sharing, Government Cloud, edition differences

2. License Types

• Licensing: Full CRM, Platform, Experience Cloud, Identity, Chatter, Einstein, Data Cloud, MuleSoft, Tableau, Shield, Industry Clouds, feature vs permission set licenses, cost optimization

3. Mobile Solutions

• Mobile Strategy: Salesforce Mobile App, Mobile Publisher, PWA, Mobile SDK, offline capabilities (Briefcase, SmartStore), MDM, Field Service mobile, push notifications
• Field Service Architecture: Work Orders, Service Appointments, scheduling optimization (ESO), territory design, Dispatcher Console, mobile offline (Briefcase), preventive maintenance, Agentforce for Field Service

4. Reporting & Analytics

• Reporting & Analytics: Standard Reports vs CRM Analytics vs Tableau vs Data Cloud, historical trending, Analytic Snapshots, Einstein Discovery, architecture patterns

5. Document Management

• Document Management: Salesforce Files vs external DMS, Files Connect, Knowledge management, document generation, e-signature, storage optimization

6. On/Off-Platform Systems

• Platform Capabilities & Constraints: Governor limits, multi-tenant architecture, on vs off platform decision framework, async Apex patterns, Platform Events, CDC, Big Objects, Custom Metadata

Cross-Cutting Guides

• Decision Guides: Mermaid decision flowcharts for every major system architecture decision
• Best Practices & Anti-Patterns: Platform-first thinking, Well-Architected Framework alignment, common anti-patterns
• Trade-Offs: On/off platform, single/multi-org, build vs buy, license optimization, mobile, reporting, document management

Practice

• Domain Grilling: D1 System Architecture Q&A

Key Exam Focus Areas

The review board probes Domain 1 along specific fault lines. These are the areas where candidates most commonly lose credibility:

• Default to single-org, then name the forcing function. The most frequent Domain 1 mistake is proposing multi-org without exhausting single-org options first. Hyperforce data residency resolves many regulatory objections. Unlocked packages and sandbox strategies resolve many release cadence conflicts. State single-org as your recommendation, then walk through the specific signals in the scenario that override it. “Multi-org is required because the scenario specifies FedRAMP High authorization, which Hyperforce cannot satisfy for commercial cloud” is defensible. “Multi-org because the business units are different” is not.

• Know the N x (N-1)/2 formula and cite it. When a scenario involves multiple orgs and cross-org data sharing, the board expects you to dismiss peer-to-peer topology for more than three orgs and cite the integration scaling formula. Five orgs need ten connections under peer-to-peer. Ten orgs need 45. Hub-and-spoke or federated architectures with a middleware layer are the correct answer; the formula is the justification.

• M&A scenarios always probe the coexistence phase. Candidates who jump to “we merge the orgs” without addressing the 12-18 month transition period lose credibility immediately. Coexistence is not optional — users in both orgs must keep working during consolidation, which means temporary integration investment. Present the phased plan: Day 1 coexistence strategy, interim integration layer, data mapping and migration, then cutover.

• Standard reports before CRM Analytics, CRM Analytics before Tableau. The escalation principle is a point-scoring opportunity. Recommend standard reports as the default. Escalate only when you can cite a specific gap: more than a four-object join, historical trending beyond three months, predictive analytics, non-Salesforce consumers, or multi-source data. Boards look for cost-consciousness, and jumping to CRM Analytics for a simple count-by-status report signals poor platform knowledge.

• Mobile Publisher is a branding solution, not a functionality solution. A common trap: the scenario mentions “custom branded mobile app” and candidates propose Mobile SDK. If standard Salesforce Mobile App functionality is sufficient, Mobile Publisher is the answer. It wraps the same experience with a custom icon, splash screen, and app store listing. If the functionality gap is real — complex offline sync, native Bluetooth or NFC, full UI control — then Mobile SDK is justified. Never justify Mobile SDK on branding alone.

• Sync, then async, then off-platform. Governor limit questions have a standard answer structure. Evaluate whether the requirement fits within synchronous limits. If not, evaluate async processing (which provides 2x SOQL queries and 6x CPU time). Only if async limits are still insufficient does off-platform become the correct recommendation. Skipping directly to “we’ll use an external compute layer” without exhausting async processing signals weak platform depth.

• License type mismatches are a common scoring pitfall. External portal users should never receive full CRM licenses. Back-office users who only need a custom app but not Opportunities or Cases should use Platform licenses. When a scenario specifies an external partner portal with complex record sharing, the answer is Customer Community Plus (not Customer Community) because the role hierarchy and sharing rules are required. Know the object access differences between license types cold.

• Custom Metadata Types, not Custom Settings, for deployable configuration. When the scenario mentions CI/CD, change sets, or environment management, Custom Metadata Types are the correct answer for configuration data. Custom Settings are not deployable — they must be loaded manually in each environment, which breaks automated deployment pipelines. This is a detail that separates candidates who know the platform from those who learned it from documentation only.

Related Topics

System architecture intersects with every other domain. The strongest connections:

• Security Architecture: Security requirements determine whether orgs can share data or must be isolated. Identity architecture (SSO, SAML, OIDC) is a system architecture input. Shield licensing for encryption and audit must be factored into edition selection. Data classification drives sharing model design which in turn constrains org topology.

• Data Architecture: Large data volume (LDV) thresholds directly influence org partitioning decisions. An org with 50M+ records on a high-skew object may need to be split or archived before adding another business unit. Storage planning (data vs file vs Big Object) is a joint Domain 1 and Domain 3 responsibility. Data residency requirements surface in both domains.

• Solution Architecture: The platform-first decision ladder (declarative before code, code before AppExchange, AppExchange before off-platform) is the common thread. Build vs buy evaluation criteria overlap between the two domains. Declarative-first principles in Domain 4 reinforce the same principle applied to system-level decisions in Domain 1.

• Integration Architecture: Cross-org data sharing patterns are integration patterns. When multi-org is selected, every cross-org data flow is an integration problem. API call limits (per-24-hour), Platform Events throughput, and CDC delivery guarantees are system architecture constraints that integration design must respect. MuleSoft licensing and API-led connectivity patterns straddle both domains.

• Development Lifecycle: Org strategy determines sandbox strategy. A multi-org architecture requires paired sandboxes and coordinated refresh schedules, which adds operational overhead that must be budgeted. Custom Metadata Types over Custom Settings is a joint Domain 1 and Domain 6 decision — it exists because CMTs are deployable through CI/CD pipelines. Edition selection affects sandbox availability (number and type of sandboxes per org).

• Communication & Presentation: Every Domain 1 decision must be defensible under board questioning. Trade-off articulation — “I chose X because of benefit A, and I accept the trade-off of limitation B, which I mitigate by doing C” — is as important as the decision itself. The ability to quickly reconstruct the decision logic from the scenario signals the kind of mature architectural thinking boards reward.

Frequently Asked Questions

What topics does the CTA exam cover in System Architecture?

Org strategy (single vs multi-org), licensing models, mobile solutions (Salesforce Mobile, Mobile Publisher, PWA, offline), reporting and analytics (standard reports, CRM Analytics, Tableau, Data Cloud), document management, and platform capabilities including governor limits and multi-tenant architecture constraints.

How is System Architecture scored in the CTA review board?

Judges look at whether the solution uses platform capabilities properly while staying within governor limits and multi-tenant constraints. They probe for justified org strategy decisions, correct license type selection, and a clear on-platform vs off-platform decision framework backed by trade-off analysis.

What are the most common mistakes in System Architecture during the CTA exam?

Defaulting to custom code when declarative or platform-native solutions exist. Ignoring governor limits. Choosing multi-org without strong justification. Overlooking mobile and offline requirements buried in the scenario. Underestimating reporting volume against platform limits.

How should I approach single-org vs multi-org decisions at the CTA review board?

Default to single-org unless the scenario presents a strong reason for separation: regulatory data residency requirements, M&A with incompatible data models, or fundamentally different business units with conflicting security models. Always name the trade-offs. Multi-org increases integration complexity, makes cross-org reporting harder, and raises total cost of ownership.

What platform limits should I memorize for the CTA exam?

Focus on limits that affect architectural decisions: API call limits per 24 hours, Bulk API batch sizes, data storage allocation per license type, custom object limits, SOQL query row limits, Apex CPU time limits, Platform Event delivery guarantees, and file storage caps. Know the thresholds that trigger an off-platform decision rather than memorizing exact numbers.