Domain Coverage & Hidden Requirements

The 9 essential artifacts mapped to scoring domains, a domain-by-domain coverage guide with common pitfalls, hidden requirements, and techniques for handling intentional ambiguity in CTA scenarios.

Domain Coverage in the Solution

The 9 Essential Artifacts

Each artifact maps to one or more scoring domains. This table is a checklist for complete coverage:

#	Artifact	Primary Domain(s)	Must Include
1	Company Overview / Context	Communication	Business context, project scope, key stakeholders, success criteria
2	Actors & Licenses	System Architecture, Security	All user types, license types, access channels (web, mobile, community)
3	System Landscape	System Architecture, Integration	All Salesforce orgs, all external systems, all integration points with patterns and protocols
4	Data Model	Data	Key objects (standard + custom), relationships, cardinality, volumes, external data references
5	Role Hierarchy & Sharing	Security	Role hierarchy tree, OWD settings, sharing rules, territory model if applicable
6	Identity & Access (SSO Flow)	Security	Authentication flow, identity providers, SSO protocols, MFA, portal access
7	Data Migration Strategy	Data	Source-to-target mapping approach, sequencing, tooling, data quality strategy, cutover plan
8	Governance Model	Dev Lifecycle, Communication	Decision-making structure, program governance, change management, stakeholder cadence
9	Development & Deployment	Dev Lifecycle	Environment strategy, branching model, CI/CD approach, release cadence, testing strategy

Domain-by-Domain Coverage Guide

Domain 1: System Architecture - What Judges Expect

Cover in the presentation:

• Justification for single-org vs. multi-org strategy
• License type selection with rationale (Sales Cloud, Service Cloud, Experience Cloud (formerly Community Cloud), etc.)
• Reporting and analytics approach (native reports, CRM Analytics (formerly Tableau CRM), external BI)
• Mobile strategy (Salesforce Mobile App, custom Lightning app, hybrid)
• Document management approach (Files, CMS, external DMS)
• AppExchange products selected (with rationale)

Common pitfalls:

• Selecting licenses without explaining capability trade-offs
• Ignoring mobile requirements
• Not addressing reporting for executive stakeholders
• Defaulting to single-org without considering multi-org factors

Domain 2: Security - What Judges Expect

Cover in the presentation:

• End-to-end identity management flow (who authenticates where and how)
• SSO architecture with protocol selection (SAML, OAuth, OpenID Connect)
• Role hierarchy design with clear rationale
• OWD (Organization-Wide Defaults) settings per object with justification
• Sharing rules (criteria-based, ownership-based, manual)
• Territory management if applicable
• Field-level security approach
• Data encryption strategy (Shield Platform Encryption where needed)
• Portal/community security model
• MFA and IP restrictions

Common pitfalls:

• Vague or generic security diagrams
• Not showing the complete identity flow from user to system
• Forgetting external user access patterns (community, portal, API)
• Not addressing data visibility between business units

Domain 3: Data - What Judges Expect

Cover in the presentation:

• Data model with standard vs. custom objects justified
• Large data volume (LDV) strategy - skinny tables, indexing, archival
• Data migration approach with tooling (Data Loader, Informatica, Jitterbit, etc.)
• Migration sequencing (parent objects before children, reference data first)
• Data quality and deduplication strategy
• Data archival and retention policy
• External data strategy (Salesforce Connect, data warehousing)
• Master data management approach

Common pitfalls:

• Over-customizing when standard objects would work
• Not addressing LDV even when scenario implies millions of records
• No clear migration sequencing or cutover plan
• Ignoring data quality issues mentioned in current state

Domain 4: Solution Architecture - What Judges Expect

Cover in the presentation:

• Declarative vs. programmatic decision rationale for each major feature
• AppExchange product evaluation criteria and selections
• Build vs. buy analysis for key capabilities
• How the solution uses platform capabilities (Flow, Lightning). Process Builder is deprecated; use Flow for all new automation.
• Off-platform components and their justification
• How all requirements are addressed (map requirements to solution components)

Common pitfalls:

• Defaulting to code when declarative solutions exist
• Including AppExchange products without understanding how they work
• Not mapping every requirement to a solution component
• Ignoring platform limits and governor constraints

Domain 5: Integration - What Judges Expect

Cover in the presentation:

• Integration pattern for each external system (sync vs. async, request-reply vs. fire-and-forget, batch vs. real-time)
• Technology selection per integration (REST, SOAP, Platform Events, Change Data Capture, MuleSoft, middleware)
• Error handling and retry strategy
• Authentication between systems
• Data transformation approach
• Integration monitoring and alerting
• Middleware/ESB justification if used
• High availability and failover considerations

Common pitfalls:

• Using the same integration pattern for every system
• Not addressing error handling and dead letter queues
• Ignoring data transformation requirements
• Not justifying middleware when point-to-point would suffice (or vice versa)

Domain 6: Development Lifecycle & Deployment - What Judges Expect

Cover in the presentation:

• Environment strategy (dev, QA, UAT, staging, prod) with clear purpose for each
• Source control strategy (Git branching model)
• CI/CD pipeline approach
• Release management cadence and strategy
• Testing strategy (unit, integration, UAT, regression, performance)
• Risk identification and mitigation plan
• Program governance model (steering committee, working groups, decision escalation)
• Team structure recommendation
• Delivery methodology (Agile, Waterfall, Hybrid) with justification

Common pitfalls:

• Generic governance without tying it to the scenario
• Not addressing how parallel development streams are managed
• Missing test strategy or treating it as an afterthought
• No clear risk register

Domain 7: Communication - What Judges Expect

Demonstrate through the presentation:

• Clear, logical narrative flow
• Clean, readable diagrams with legends and labels
• Confident articulation of decisions and trade-offs
• Ability to handle objections constructively
• Appropriate level of detail (not too deep, not too shallow)
• Time management (finishing within 45 minutes)
• Graceful handling of uncertainty

Common pitfalls:

• Reading from slides instead of speaking naturally
• Diagrams that are too cluttered or unlabeled
• Defensive reactions to judge pushback
• Running out of time before covering all domains
• Over-talking on one topic at the expense of others

---

Hidden Requirements - How to Identify Implicit Requirements

Categories of Hidden Requirements

CTA scenarios are deliberately written with both explicit and implicit requirements. Passing candidates identify and address both.

Non-Functional Requirements (Almost Never Stated Explicitly)

These are rarely written in the scenario but are always expected in your solution:

NFR Category	What to Look For in the Scenario	What to Address
Performance	Data volume numbers, user counts, real-time references	LDV strategies, caching, async processing, query optimization
Scalability	Growth projections, “plans to expand” language	Scalable architecture, multi-tenant considerations, elastic design
Availability	Global operations, 24/7 references, mission-critical language	Disaster recovery, backup strategy, SLA commitments
Security	Regulated industry, data sensitivity mentions	Encryption, audit trails, compliance frameworks
Maintainability	Multiple development teams, ongoing operations	Code standards, documentation, governance, technical debt management
Usability	End-user adoption concerns, diverse user base	Training strategy, user experience design, change management

Requirements Buried in Context

These are stated in the scenario but easy to overlook:

• Offhand mentions of mobile access in a stakeholder quote
• Reporting requirements embedded in a paragraph about business processes
• Compliance obligations mentioned once in the company overview
• Timeline constraints buried in stakeholder expectations
• Data quality issues described as part of the current state narrative
• Change management needs implied by references to user resistance
• Internationalization needs implied by multiple regions or languages

Requirements Implied by Industry

Certain industries carry implicit requirements even if the scenario does not state them:

Industry	Implicit Requirements
Healthcare	HIPAA compliance, PHI handling, consent management, audit trails
Financial Services	SOX compliance, PCI DSS, data encryption, regulatory reporting
Government	FedRAMP, data sovereignty, accessibility (Section 508), data classification
Retail	PCI compliance for payments, seasonal scaling, consumer privacy (CCPA/GDPR)
Any global company	Data residency, GDPR, multi-language, multi-currency, time zone handling

How to Surface Hidden Requirements

1. Ask “so what?” for every fact stated. If the company has 50,000 records per month, that is a clue about LDV strategy.
2. Count the user types - every distinct user type needs its own access pattern, license consideration, and security model
3. Map the data lifecycle - where does data originate, where does it flow, where does it end up?
4. Look for the word “also” - requirements after “also” in a sentence are frequently missed
5. Check stakeholder quotes - business leaders’ concerns often contain implicit requirements
6. Consider what is NOT said - if the scenario describes a global company but does not mention data residency, address it anyway

---

Ambiguity Handling - Dealing with Intentional Ambiguity

Why Scenarios Are Ambiguous

Ambiguity in CTA scenarios is deliberate. The exam tests the ability to:

• Handle vague client requirements (a daily reality for architects)
• Make reasonable assumptions under uncertainty
• Demonstrate problem-solving when information is incomplete
• Manage risk by identifying and addressing unknowns
• Show judgment about what questions to ask, even when they cannot be asked during the exam

The Assumption Framework

When ambiguity appears, this structured approach works well:

Step 1: Identify the ambiguity - What exactly is unclear?

Step 2: Assess impact - Does this ambiguity affect the solution direction? If two interpretations lead to the same architectural decision, the ambiguity is low-impact. Note it briefly and move on.

Step 3: State your assumption - Clearly declare what you are assuming and why.

Step 4: Design for the assumption - Build your solution based on the stated assumption.

Step 5: Note the alternative - Briefly describe what would change if the assumption were wrong.

The Five-Finger Communication Method

When presenting a requirement that involves ambiguity, use this structure (attributed to Johann Furmann / Cloud Johann):

1. “In order to…” - state the business requirement
2. “I recommend…” - state your solution
3. “Assuming that…” - state your assumption
4. “I considered…” - name the alternative approach
5. “But I chose this because…” - justify your decision

Example

“In order to support the real-time inventory sync between SAP and Salesforce, I recommend a Platform Events-based integration using MuleSoft as middleware, assuming that the SAP system supports outbound real-time notifications. I considered a batch polling approach, but I chose the event-driven pattern because the scenario mentions the need for ‘near real-time’ visibility into inventory levels for the sales team.”

Types of Ambiguity to Expect

Ambiguity Type	Example	How to Handle
Vague volumes	”The company has a large customer base”	State an assumption (e.g., “Assuming 500K+ accounts”), then design for LDV
Unclear integration direction	”Data must be shared between SAP and Salesforce”	Define which system is master, state the assumption, design bidirectional if needed
Missing user counts	No mention of how many community users	Estimate based on context (customer count, partner count), state your assumption
Ambiguous timeline	”The project should be completed in phases”	Define the phases yourself, justify the sequencing
Conflicting requirements	Performance vs. real-time data freshness	Acknowledge the tension, choose a balanced approach, justify the trade-off
Unspecified compliance	Global company with no mention of GDPR	Address it anyway - judges expect you to identify implicit compliance needs

What NOT to Do with Ambiguity

• Do not ignore it - pretending ambiguity does not exist is a red flag
• Do not over-assume - too many assumptions signals lack of experience
• Do not ask the judges - during preparation and presentation, requirements cannot be clarified (during Q&A, judges may steer, but do not count on it)
• Do not hedge everything - pick a direction and commit. Judges want decisiveness with intellectual honesty.