Domain Coverage & Hidden Requirements
The 9 essential artifacts mapped to scoring domains, domain-by-domain coverage guide with common pitfalls, hidden requirements, and how to handle intentional ambiguity in CTA scenarios.
Domain Coverage in Your Solution
The 9 Essential Artifacts
Each artifact maps to one or more scoring domains. Use this as your checklist to ensure 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 your presentation:
- Justification for single-org vs. multi-org strategy
- License type selection with rationale (Sales Cloud, Service Cloud, Experience Cloud, etc.)
- Reporting and analytics approach (native reports, CRM Analytics, 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 your 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 your 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 your 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 leverages platform capabilities (Flow, Lightning). Note: 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 your 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 your 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 your 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. Successful 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 miss:
- 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 a paragraph about stakeholder expectations
- Data quality issues described as part of 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
- Ask “so what?” for every fact stated — if the company has 50,000 records per month, that is a clue about LDV strategy
- Count the user types — every distinct user type needs its own access pattern, license consideration, and security model
- Map the data lifecycle — where does data originate, where does it flow, where does it end up?
- Look for the word “also” — requirements after “also” in a sentence are frequently missed
- Check stakeholder quotes — business leaders’ concerns often contain implicit requirements
- Consider what is NOT said — if the scenario describes a global company but does not mention data residency, you should still address it
Ambiguity Handling — Dealing with Intentional Ambiguity
Why Scenarios Are Ambiguous
Ambiguity in CTA scenarios is a deliberate design choice. The exam tests your 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 if you cannot ask them in the exam)
The Assumption Framework
When you encounter ambiguity, use this structured approach:
Step 1: Identify the ambiguity — What exactly is unclear?
Step 2: Assess impact — Does this ambiguity affect your solution direction? If two interpretations lead to the same architectural decision, the ambiguity is low-impact and you can 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):
- “In order to…” — state the business requirement
- “I recommend…” — state your solution
- “Assuming that…” — state your assumption
- “I considered…” — name the alternative approach
- “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 — making too many assumptions signals lack of experience
- Do not ask the judges — during preparation and presentation, you cannot clarify requirements (during Q&A, judges may steer you, but do not count on it)
- Do not hedge everything — pick a direction and commit. Judges want to see decisiveness with intellectual honesty