Domain Deep Dive

Each domain is scored independently. Salesforce does not publish percentage weightings; every domain must be passed. Understanding what judges look for in each domain — and the mistakes that trip candidates up — is essential for targeted preparation.

Domain 1: System Architecture (6 objectives)

What the board evaluates:

• Appropriate mix of on-platform and off-platform systems
• Reporting and analytics strategy
• Single-org vs. multi-org considerations
• Mobile solution design
• License type selection (judges expect you to know what each license grants down to the object level)
• Document management approach

Common pitfalls: License choices that do not support the standard objects in the data model. Not knowing the difference between Sales Cloud, Service Cloud, and Experience Cloud license capabilities.

Domain 2: Security (6 objectives)

What the board evaluates:

• Platform security mechanisms (OWD, sharing rules, role hierarchy, profiles, permission sets)
• Portal and community security architecture
• Declarative vs. programmatic security (when to use each)
• Object and field-level security
• End-to-end identity management (SSO, OAuth, SAML)

Common pitfalls: Inability to describe identity flows at the SAML attribute level. Not knowing when to use implicit sharing vs. sharing rules vs. Apex-managed sharing. Overlooking the security implications of community and portal users.

Domain 3: Data (3 objectives)

What the board evaluates:

• Large Data Volume (LDV) architecture and optimization
• Data modeling concepts and database design
• Data migration strategy and tool selection

Common pitfalls: This is the domain candidates most frequently get partially wrong. Generic “Extract-Format-Dedupe-Load” migration strategies instead of tailored ones. Not addressing LDV mitigation (skinny tables, indexing, archiving). A data model that fails to support all requirements across all sections.

Data is foundational

The data model must support EVERY other section: security (sharing model depends on object hierarchy), integration (data must be available for integrations), reporting (data structure determines what reports are possible), and solution architecture (object choices affect automation options). Get data wrong and everything else collapses.

Domain 4: Solution Architecture (2 objectives)

What the board evaluates:

• Config vs. customize vs. code vs. buy decisions
• Trade-offs of incorporating external applications (AppExchange, third-party)

Common pitfalls: Not knowing when to use declarative (Flow) vs. programmatic (Apex, LWC). Process Builder is deprecated; always recommend Flow. Not considering AppExchange solutions where appropriate. Inability to explain component-level integration end-to-end.

Domain 5: Integration (4 objectives)

What the board evaluates:

• Enterprise integration landscape design
• Technology selection and justification (MuleSoft, middleware, point-to-point)
• Integration patterns (request-reply, fire-and-forget, batch, near-real-time, pub/sub)
• Platform-specific integration technology (REST, SOAP, Platform Events, Change Data Capture, Salesforce Connect)

Common pitfalls: Not distinguishing ESB (for orchestration) from ETL (for heavy data lifting). Missing error handling, retry strategies, and monitoring in integration design. Not addressing data availability for reporting after integration.

Domain 6: Development Lifecycle and Deployment (6 objectives)

What the board evaluates:

• Risk identification and mitigation strategies
• Methodology choices (Agile, waterfall, hybrid) fitting the customer context
• Full test strategy
• Governance frameworks
• Environment management (sandbox strategy)
• Source control and CI/CD (branching strategy aligned with release management)

Common pitfalls: Cookie-cutter “we’ll use Agile with Scrum” without considering the customer’s actual environment. Not identifying project-specific risks. Governance treated as an afterthought rather than woven throughout the solution.

Domain 7: Communication (3 objectives)

What the board evaluates:

• Articulation of benefits, limitations, design choices, and trade-offs
• Use of visualization and documentation tools (diagrams are critical)
• Handling unexpected roadblocks and objections

Common pitfalls: Treating this as a “soft” domain when it is explicitly scored. Unreadable or incorrect diagrams. Inability to handle pushback gracefully. Verbose, unfocused answers during Q&A.

Cross-Cutting Themes

Judges evaluate these themes across all seven domains, not in isolation:

• Trade-off analysis — every design decision should present alternatives with pros and cons, not just a single recommendation
• Risk identification — proactively call out risks and pair each one with a mitigation strategy
• Justification — explain why you chose a particular approach, not just what you chose
• Platform-first thinking — demonstrate deep knowledge of native Salesforce capabilities before reaching for custom code or third-party tools
• Scalability — show that the solution works not only at launch but as the customer grows in data volume, user count, and org complexity

See Domains and Scoring for the full objectives table across all 30 objectives.

Sources

• CTA Exam Guide (PDF) — official exam objectives and domain breakdown (30 objectives across 7 domains)
• CTA Certification Guide and Tips — Salesforce Ben (Sebastian Wagner)
• What It Takes to Fail the CTA Exam — Martin Humpolec
• Review Board Evaluation Guide — Dinesh Yadav
• 5 Tips for Acing the CTA Review Board — Keir Bowden (Bob Buzzard)