Presentation Structure & Storytelling
How to structure your 45-minute CTA Review Board presentation using storytelling techniques, time management, and a business-first narrative.
Presentation Flow: Structuring the 45 Minutes
The Three-Act Structure
Think of your presentation as a story with a beginning, middle, and end that the judges can recognize and navigate easily.
flowchart LR
subgraph Act1["Act 1: Opening (3-5 min)"]
A1["Business Context"] --> A2["Critical Requirements"]
A2 --> A3["Assumptions"] --> A4["Approach Preview"]
end
subgraph Act2["Act 2: Architecture (25-35 min)"]
B1["System Landscape"] --> B2["Data Model"]
B2 --> B3["Integration"] --> B4["Security & Identity"]
B4 --> B5["Actors & Licenses"]
B5 --> B6["Migration"] --> B7["Governance"]
end
subgraph Act3["Act 3: Close (2-3 min)"]
C1["Top 3 Decisions"] --> C2["Key Trade-offs"]
C2 --> C3["Risks & Confidence"]
end
Act1 --> Act2 --> Act3
Act 1: Opening (3-5 minutes) — Set the Stage
Goal: Show that you understood the scenario and can frame the problem like a senior architect briefing a CXO.
- State your understanding of the business context — summarize the company, its industry, and the key business drivers in 2-3 sentences
- Identify the critical requirements — call out the top 3-5 requirements that shaped your architecture (both functional and non-functional)
- Declare your assumptions — any ambiguities you resolved with explicit assumptions (judges respect this)
- Preview your approach — one sentence that frames your overall architectural philosophy for this scenario (e.g., “I’ve designed a platform-first solution with selective use of middleware for the high-volume integration requirements”)
Opening formula
“The scenario describes [company type] facing [core challenge]. The critical requirements driving my architecture are [1, 2, 3]. I’ve assumed [key assumption]. My approach prioritizes [architectural philosophy] because [reason].”
Act 2: Middle (25-35 minutes) — Walk Through the Architecture
Goal: Walk through each artifact with a clear narrative, tying every decision to a requirement.
Present your artifacts in a logical flow. A proven sequence:
| Order | Artifact | Time | What to Cover |
|---|---|---|---|
| 1 | System Landscape | 4-5 min | All systems, their roles, interactions, and protocols |
| 2 | Data Model | 4-5 min | Key objects, relationships, cardinality, LDV considerations |
| 3 | Integration Architecture | 4-5 min | Data flows, sync/async, protocols, error handling |
| 4 | Security & Identity | 3-4 min | Authentication, authorization, sharing model, portal security |
| 5 | Actors & Licenses | 2-3 min | User types, license recommendations, access patterns |
| 6 | Role Hierarchy | 2-3 min | Sharing model, territory management if applicable |
| 7 | Data Migration | 2-3 min | Strategy, tools, sequencing, validation |
| 8 | Governance & DevOps | 3-4 min | Environments, CI/CD, release strategy, testing |
| 9 | Project Risks & Mitigations | 2-3 min | Top risks with concrete mitigation strategies |
For each artifact, follow this pattern:
- Identify the requirement — “This addresses the requirement for…”
- State your recommendation — “I recommend…”
- Explain why — “Because…”
- Acknowledge trade-offs — “The trade-off here is…”
- Note alternatives considered — “I considered X but chose Y because…”
The biggest mistake
Do not do “solution dumps” where you describe what you built without tying it to requirements. If judges do not know what you are solving for, they cannot score you on whether you meet the requirements. Every solution must be tied to a requirement.
Act 3: Closing (2-3 minutes) — Summarize Key Decisions
Goal: Leave judges with a clear mental model of your architecture and its strengths.
- Recap your top 3 architectural decisions and why they matter
- Restate key trade-offs you made and why they were acceptable
- Acknowledge top risks and your mitigation strategies
- Express confidence — “I believe this architecture addresses the core requirements because…”
The 12-Section Operational Structure
The Three-Act Structure above is a pedagogical framework — it teaches you HOW to think about presentation flow. The 12-section structure below is an operational checklist — it tells you exactly WHAT to cover and WHEN. Both complement each other: use the Three-Act for narrative planning, use the 12-section for execution.
This structure is validated across 13+ mock boards and used by successful candidates including those coached by Cloud Johann, FlowRepublic, and CTA Gang of Four.
| # | Section | Time | What to Cover | Maps to Three-Act |
|---|---|---|---|---|
| 1 | Company Overview | 0-2 min | Company background, project goals, timeline, key business drivers | Act 1: Opening |
| 2 | Org Strategy | 2-4 min | Single vs multi-org decision with justification, multi-currency, translations | Act 1: Opening |
| 3 | Risks & Assumptions | 4-5 min | Dependency risks, budget assumptions, key constraints, ambiguity resolutions | Act 1: Opening |
| 4 | Actors & Licenses | 5-8 min | All user types, license types (Sales/Service/Community/Platform), cost implications | Act 2: Architecture |
| 5 | Role Hierarchy | 8-12 min | Security model foundation — role tree, territory management, access inheritance | Act 2: Architecture |
| 6 | System Landscape | 12-15 min | All systems, middleware (MuleSoft/ESB), SSO, integration layer with legends | Act 2: Architecture |
| 7 | Data Model | 15-22 min | Standard/custom objects, relationships, LDV strategy, OWD overlay | Act 2: Architecture |
| 8 | Business Requirements | 22-30 min | Requirement-to-solution mapping with justification for every key decision | Act 2: Architecture |
| 9 | Data Migration | 30-35 min | Strategy, phases, tools, what to disable during load, validation criteria | Act 2: Architecture |
| 10 | Sharing & Accessibility | 35-38 min | OWD settings, sharing rules, Apex managed sharing, FLS, restriction rules | Act 2: Architecture |
| 11 | Reporting | 38-40 min | Standard reports, trending analytics, off-platform needs, forecasting | Act 2: Architecture |
| 12 | Project & Deployment | 40-45 min | CI/CD pipeline, branching strategy, testing approach, governance, release plan | Act 3: Close |
Why Role Hierarchy comes BEFORE System Landscape
Most candidates put System Landscape first because it feels like the natural starting point. But the 12-section order puts Role Hierarchy first because the sharing model is foundational — it constrains every other design decision. Judges who have seen the security model first can evaluate all subsequent sections through that lens.
Section 11 (Reporting) is often forgotten
Many candidates skip reporting entirely or treat it as an afterthought. If the scenario mentions analytics, dashboards, forecasting, or data availability requirements, you MUST address reporting explicitly. Even a 2-minute overview shows the judges you considered it.
Mapping the Two Structures
Use both structures together:
- Planning phase (180 min): Use the 12-section list as a BUILD checklist — ensure you have content for every section
- Presentation phase (45 min): Use the Three-Act narrative flow — open with context (sections 1-3), walk through architecture (sections 4-11), close with deployment and risks (section 12)
- The 12-section order is not rigid — adapt the sequence if your scenario demands it (e.g., if integration is the dominant domain, you might present System Landscape + Integration Architecture together before Data Model)
The 90-Second Diagram Rule
Practice presenting each diagram in under 90 seconds with a clear narrative:
“This diagram shows [what it represents]. The key decision here is [decision]. The trade-off is [trade-off]. This connects to [next diagram/requirement] because [reason].”
Time Management During Presentation
flowchart LR
T0["0 min\nStart"] --> T5["5 min\nOpening done"]
T5 --> T15["15 min\nCheck: Landscape +\nData Model done"]
T15 --> T30["30 min\nCheck: Integration +\nSecurity done"]
T30 --> T40["40 min\nAll artifacts\npresented"]
T40 --> T43["43 min\nClosing\nsummary"]
T43 --> T45["45 min\nQ&A begins"]
style T15 fill:#e8a838,color:#fff
style T30 fill:#e8a838,color:#fff
style T45 fill:#2ecc71,color:#fff
Pacing checkpoints
If you are not past the data model by minute 15, you are behind. Skip detail on lower-risk artifacts and summarize. If you are ahead of schedule at minute 30, use the extra time to proactively address trade-offs — do not pad with filler.
- Do not repeat yourself. You have finite time. Repeating elements of your solution wastes precious minutes.
- Be concise. Your answers should be CC — correct and concise.
- Keep a mental clock. Know roughly where you should be at the 15-minute and 30-minute marks.
- Do not read slides. Speak to the diagrams; do not narrate bullet points.
Storytelling Techniques
The CTA presentation is not a technical document — it is an architectural narrative. You are telling the story of how your architecture solves a business problem.
The Business-First Narrative
Frame every technical decision as a business outcome:
| Instead of… | Say… |
|---|---|
| ”I used MuleSoft for integration" | "The high-volume, real-time data requirements between the ERP and Salesforce led me to recommend middleware to ensure reliability and provide circuit-breaking capabilities" |
| "I chose Community licenses" | "Given the 50,000 external partner users who need limited case and knowledge access, Partner Community licenses provide the right capability at the right cost point" |
| "I added a CDN" | "To meet the 2-second page load SLA for the 15 global office locations, I’ve introduced a CDN layer to reduce latency for static assets” |
The SACV Framework
Evaluate and present every architecture decision through four lenses:
- Simplicity — Is this the simplest approach that meets the requirement?
- Appeal — Does this resonate with the business stakeholders?
- Change — How adaptable is this when requirements evolve?
- Value — What is the cost/benefit trade-off?
Story Arc for Each Decision
Present every major decision as a mini-narrative following this arc:
flowchart LR
CTX["Context\n'The scenario\nrequires...'"] --> CH["Challenge\n'The difficulty\nis...'"]
CH --> DEC["Decision\n'I chose...'"]
DEC --> WHY["Justification\n'Because...'"]
WHY --> TR["Trade-off\n'I accept...'"]
TR --> MIT["Mitigation\n'I address\nthat by...'"]
Connecting the Dots
Your architecture should feel like an interconnected narrative, not isolated slides:
- “This data model decision connects directly to the integration pattern I showed earlier…”
- “The sharing model I designed here is driven by the multi-tenant portal requirement we discussed…”
- “This deployment strategy accounts for the phased rollout risk I identified in the governance section…”
Communication Domain Tips (Domain 7)
Domain 7 is independently scored and covers three objectives. It is assessed throughout both the presentation and Q&A — there is no separate “communication section.”
Objective 7.1: Articulate Benefits, Limitations, and Design Choices
- Always state the “why” before the “what”
- Use the format: “I recommend [X] because [business reason]. The limitation is [Y], which I mitigate by [Z]”
- Handle objections by first acknowledging the valid point, then providing your reasoning
- Speak in both languages: translate between business terms and technical terms naturally
Objective 7.2: Use Visualization and Documentation Tools
- Diagrams must be readable — not just correct, but clear to the judges
- Use consistent notation — legends, color coding, and standardized shapes (use the Salesforce Shape Library in Lucidchart)
- Label everything — every arrow, every system, every data flow
- Layer your diagrams — start with the high-level context and drill down for technical audiences
Objective 7.3: Handle Unexpected Roadblocks
- When a judge introduces a new constraint, pause and assess the impact across your entire architecture, not just the immediate area
- When you realize you made a mistake, correct it openly: “On reflection, a better approach would be…”
- When requirements conflict, identify the conflict explicitly and propose how you would facilitate a decision with stakeholders
Communication Scoring Indicators
Judges assess communication holistically. What separates pass from fail:
| Passing Communication | Failing Communication |
|---|---|
| Ties every solution to a requirement | Describes solutions without context |
| Proactively identifies trade-offs | Only mentions trade-offs when asked |
| Adapts when challenged with new info | Rigidly defends everything |
| Speaks concisely and stays on time | Rambles, repeats, or runs out of time |
| Diagrams are clear and well-labeled | Diagrams are cluttered or unreadable |
| Acknowledges gaps honestly | Bluffs or gives vague answers |
| Balances business and technical language | Speaks only in technical jargon |
Body Language and Confidence
Even in a virtual format, non-verbal communication matters. The judges can see you on camera.
Virtual Presentation Best Practices
- Camera on, well-lit — position your camera at eye level with good lighting so judges can see your face clearly
- Look at the camera when speaking, not at your slides — this creates eye contact with the panel
- Sit upright with open posture — leaning slightly forward conveys engagement
- Keep your arms visible and open — avoid crossing arms over your chest, which conveys being closed off
- Gesture purposefully — use hand movements to emphasize points, but do not fidget
- Manage your voice — speak at a measured pace, vary your tone, project confidence
- Smile when appropriate — especially during the opening and when handling challenges calmly
Confidence Signals
- Pause before answering — deliberate pauses signal thoughtfulness, not ignorance
- Use definitive language — “I recommend” not “I think maybe we could”
- Own your decisions — “I chose this approach because” not “This approach was chosen”
- Stay calm under pressure — if a judge pushes back hard, take a breath, restate the challenge, then respond
- Avoid filler words — minimize “um,” “uh,” “like,” “you know”
Confidence Killers to Avoid
- Apologizing for your solution before presenting it
- Reading directly from slides or notes
- Speaking too fast when nervous (practice pacing)
- Avoiding the question and talking around it
- Defensive body language when challenged
The confidence formula
A good architect is always confident and self-assured but remains honest about their knowledge. Present solutions with faith, conviction, and confidence — confidence in delivery is half the battle.