Analysis Framework & Cross-Domain Thinking

Published practice scenarios, the step-by-step scenario analysis framework, priority mapping when time runs short, and how decisions cascade across domains.

Sample Scenario Structures - Published Practice Scenarios

Publicly Available Mock Scenarios (50+ Known)

Salesforce Official Scenarios

Scenario	Size	Industry Focus	Key Challenges
City Scooter Share	Mini (3-8 pages)	Transportation / Mobility	Mobile-first, real-time tracking, consumer app
Laptop to Schools	Mini	Education / Non-Profit	Grant management, community engagement
Green Roof Systems	Mini	Environmental / Construction	IoT data, field service, project management
Greenhouse Recycling	Mini	Environmental / Waste Management	Logistics, sustainability reporting
Galaxy Cars	Full (retired)	Automotive	Dealer network, multi-stakeholder
Clean Bikes	Full (retired)	Transportation	Service management, consumer model

Community Scenarios - Andrew Hart (cta202.com)

Scenario	Industry Focus	Key Challenges
Constructus Temporary Buildings	Events / Construction	Project-based business, mobile workforce, temporary installations
Musicians Incorporated	Insurance / Entertainment	Policy management, claims processing, partner network
Hire Me Services	Staffing / HR	Candidate matching, multi-stakeholder, job board integrations
Greens & Veg	Agriculture / Food	Farm-to-table supply chain, seasonal operations
Roads for Everyone	Infrastructure / Government	Public sector, regulatory compliance, large-scale projects
High End Clothing	Retail / Fashion	Luxury retail, omnichannel, clienteling

Community Scenarios - Ladies Be Architects

Scenario	Industry Focus
Pollard Financial Services	Financial Services
Flower Racing	Entertainment / Events
Wine & Sunflowers	Agriculture / Hospitality

Community Scenarios - Flow Republic

Scenario	Industry Focus
Universal Parcel	Logistics / Delivery
Xmas Santa Clause	Seasonal Events / Retail

Community Scenarios - Packt Publishing / Tameem Bahri

Scenario	Industry Focus
Lightning Utility	Technology / SaaS
Pioneer Auto	Automotive
Digital	Technology / Media
Innovative Retailers	Retail
Medical Equipment	Healthcare / Medical Devices
Modern Furniture	Manufacturing / Retail
Online Wizz	Technology / E-Commerce
United Builders	Construction / Manufacturing
Visiting Angels	Healthcare / Home Care

Advanced Practice Scenarios - EasyLearn

Scenario	Industry Focus
Full-Length Scenario 1	Retail & Supply Chain
Full-Length Scenario 2	Healthcare & Compliance

For the complete catalog of 50+ publicly available scenarios with source links and coverage details, see Public Scenario Directory.

Scenario Size Progression for Practice

Start small, then work up to full-length scenarios:

1. Mini scenarios (3-8 pages): Baby Box, City Scooter, Green Roof - practice rapid analysis and artifact creation
2. Medium scenarios (6-8 pages): Andrew Hart collection - practice full domain coverage under time pressure
3. Full-length scenarios (8-10 pages): Universal Safety, Universal Parcel, Packt scenarios - simulate real exam conditions

Practice recommendation

Complete at least 8-10 full mock sessions (scenario analysis + artifact creation + presentation + Q&A) before attempting the real board. One CTA who passed reported completing 50+.

---

Scenario Analysis Framework - Step by Step

Figure 1. The four-phase scenario analysis framework: Orient, Extract, Architect, and Present, each with a defined time budget to keep candidates on track through the 180-minute preparation window.

Phase 1: Orient (15-20 minutes)

Objective: Understand the big picture before diving into details.

1. Skim the entire document end to end
2. Identify the company: What industry? How big? How many regions?
3. Count the systems: How many integration points exist?
4. Count the user types: Internal, external, partner, customer
5. Identify the core problem: What is the primary business driver for this project?
6. Note the complexity multipliers: Multi-org? Global? Regulated? High data volume?

Phase 2: Extract (25-35 minutes)

Objective: Pull out every requirement and constraint, organized by domain.

1. Re-read with annotation using the color-coding system
2. Create a requirements list organized by domain (even a simple bulleted list)
3. Flag ambiguities - mark items where you will need to make assumptions
4. Identify dependencies - which requirements constrain or influence others?
5. Note NFRs - performance, security, scalability requirements even if implied
6. Identify stakeholder priorities - what does each stakeholder care about most?

Phase 3: Architect (60-80 minutes)

Objective: Design the solution and create all artifacts.

1. Start with the System Landscape - this is the backbone of your solution
2. Build the Data Model concurrently
3. Design the Security Model
4. Detail the Integration Architecture
5. Define the Dev Lifecycle

Phase 4: Prepare to Present (15-20 minutes)

Objective: Structure your narrative and rehearse mentally.

1. Define your presentation order
2. Write speaking notes - key points per artifact, not a script
3. Prepare for likely Q&A topics - where are the weak spots in your solution?
4. Do a final domain checklist - verify all 7 domains are addressed
5. Practice your opening - the first 60 seconds sets the tone

---

Priority Mapping - When You Cannot Cover Everything

The Reality of Time Constraints

No candidate can cover every detail perfectly in 180 minutes of preparation and 45 minutes of presentation. Strategic prioritization is required.

Priority Tiers

Tier 1: Must Cover (failure to address these = likely domain failure)

• System Landscape with all systems and integration patterns
• Data Model with standard/custom object justification
• Role Hierarchy and sharing model
• Identity/SSO flow
• At least one integration pattern explained in detail
• Environment strategy

Tier 2: Should Cover (strengthens your score significantly)

• Data migration sequencing and tooling
• LDV strategy
• Governance model with stakeholder structure
• Testing strategy
• CI/CD approach
• Error handling for integrations

Tier 3: Nice to Cover (differentiates strong candidates)

• Change management and adoption strategy
• Detailed risk register with mitigations
• Performance optimization specifics
• Archival and data lifecycle management
• Monitoring and alerting strategy
• Cost optimization considerations

Prioritization Principles

1. Cover breadth before depth - touching all 7 domains at a basic level matters more than going deep on 4 and missing 3
2. Follow the requirements - if the scenario emphasizes data migration heavily, spend more time there
3. Address the hard problems first - judges notice when difficult requirements are avoided
4. Use Q&A as an extension - domains that were thin in the presentation can be addressed when judges ask about them
5. State what you would address - if time runs out, briefly say “In a real engagement, I would also address X, Y, Z” rather than leaving gaps unexplained

---

Cross-Domain Thinking - How Decisions Cascade

Why Cross-Domain Thinking Matters

The CTA exam tests whether candidates understand that architectural decisions are interconnected. A decision in one domain creates ripple effects across others. Judges evaluate whether these connections are visible in the solution.

Common Cross-Domain Cascades

Org Strategy —> Everything

Org Decision	Impact on Other Domains
Multi-org	Security: separate role hierarchies per org. Integration: org-to-org data sync needed. Data: data ownership per org. Dev Lifecycle: deployment to multiple targets.
Single org	Security: complex sharing model for business unit isolation. Data: higher volumes in one org. Dev Lifecycle: merge conflicts from parallel teams.

Security Model —> Data + Integration + Solution

Security Decision	Impact
Restrictive OWDs (Private)	Data: need sharing rules and apex sharing. Solution: more programmatic complexity. Integration: data visibility affects API results.
Open OWDs (Public Read)	Security: simpler but may expose data. Solution: less code. Risk: data leakage between business units.

Data Model —> Integration + Security + Performance

Data Decision	Impact
Custom objects for everything	Integration: custom API mappings needed. Security: custom FLS for every object. Dev Lifecycle: more deployment complexity.
Standard objects maximized	Integration: standard API endpoints available. Security: built-in sharing features. Performance: platform-optimized.

Integration Pattern —> Data + Security + Dev Lifecycle

Integration Decision	Impact
Middleware (MuleSoft)	Data: transformation handled outside Salesforce. Security: additional authentication layer. Dev Lifecycle: separate deployment pipeline for middleware. Cost: additional licensing.
Point-to-point APIs	Data: transformation in Salesforce. Security: direct credential management. Dev Lifecycle: tighter coupling. Cost: lower upfront, higher maintenance.

The Domino Effect

The domino effect

Changing one architectural decision mid-presentation can cascade through the entire solution. This is why the coaching guide warns: “beware of the domino effect.” If a judge challenges a core decision and the candidate changes it, the cascading impact must be understood before committing.

Figure 2. Cross-domain decision cascade: org strategy and license selection each trigger ripple effects through security, data, integration, and dev lifecycle. Changing any one node forces a re-evaluation of all connected nodes.

Cross-Domain Thinking Checklist

Before presenting, verify these cross-domain connections:

• Does the org strategy align with the security model?
• Does the data model support the integration patterns?
• Does the security model work for all user types identified?
• Does the integration architecture address error handling and retry?
• Does the dev lifecycle support the number of teams and releases needed?
• Does the license selection support all features the solution requires?
• Does the data migration plan account for security setup (roles and profiles must exist first)?
• Does the governance model match the project’s complexity and stakeholder picture?
• Do the mobile and reporting strategies work with the data model?
• Are assumptions consistent across all artifacts?

---

Additional Resources

Key Preparation Frameworks

STAR-A Framework for Q&A Responses:

• Situation - restate the challenge to confirm understanding
• Think - pause visibly before responding (valued, not penalized)
• Answer - address the specific challenge directly
• Rationale - explain the reasoning
• Adapt - revise the design if the challenge reveals a genuine gap

30-60 Second Rule for Q&A: Keep answers between 30 and 60 seconds. Use 8-14 words per sentence. If an explanation exceeds 60 seconds, the solution likely needs simplification. Confirm after each answer: “Does that answer your question?”

Handling “I Don’t Know”: Four acceptable responses:

1. Direct: “I don’t know the answer to that”
2. Bounded: “I cannot add further insight on that topic”
3. Deferral: “Can we return to that later?”
4. Redirect: “Would you like me to address a related aspect?”

Use these sparingly. More than 2-3 “I don’t know” responses signals a knowledge gap.

Exam Logistics Summary

Item	Detail
Format	Virtual with screen sharing (online only, per Salesforce Architect Program FAQ)
Panel	3 active CTAs as evaluators
Tools provided	Google Docs, Slides, Sheets, Lucidchart (Salesforce Shape Library), or paper
Presentation	~45 minutes with screen-shared diagrams
Q&A	40+ minutes of probing challenges (unused presentation time rolls over)
Scoring	Pass/Fail across 7 independent domains
Results	Written feedback within ~2 weeks
Cost	$6,000 USD initial (retake: $750 application, $2,250 board; section retake for 1 failed domain)
Prerequisites	Application Architect + System Architect credentials
First-attempt pass rate	Estimated 5-10%