Quick-Ref: Presentation Flow, Q&A Patterns & STAR-A

Scannable cheat sheet for the CTA review board presentation flow, Q&A response patterns, and the STAR-A framework. Print-and-practice reference.

Presentation Flow — The Per-Artifact Pattern

For every artifact you present, follow this 5-step pattern:

Step	Say This	Example
1. Identify requirement	”This addresses the requirement for…"	"…real-time inventory visibility across all channels”
2. State recommendation	”I recommend…"	"…a Platform Events-based integration via MuleSoft”
3. Explain why	”Because…"	"…the scenario specifies near real-time sync with 6 external systems”
4. Acknowledge trade-off	”The trade-off is…"	"…added middleware cost and operational complexity”
5. Note alternatives	”I considered X but chose Y because…"	"…point-to-point would work for 2 systems, but at 6 systems the maintenance burden exceeds middleware cost”

The 90-Second Diagram Rule

Practice explaining each diagram in under 90 seconds:

“This diagram shows [what]. The key decision is [decision]. The trade-off is [trade-off]. This connects to [next artifact] because [reason].”

STAR-A Framework for Q&A

Study-aid mnemonic

STAR-A is a study-aid mnemonic created for this vault — not an established industry framework, but a useful structure for organizing Q&A responses.

When a judge challenges your design, use this structured response:

flowchart TD
    S["S -- Situation\nRestate the challenge\n'You're asking about...'"]
    T["T -- Think\nPause 3-5 seconds visibly\nShows deliberation, not ignorance"]
    A1["A -- Answer\nAddress the specific challenge\n'In that scenario, I would...'"]
    R["R -- Rationale\nExplain your reasoning\n'Because...'"]
    A2["A -- Adapt\nUpdate design if gap is real\n'Given that, I would revise...'"]
    S --> T --> A1 --> R --> A2

STAR-A in Practice

Judge Says	S (Restate)	T (Think)	A (Answer)	R (Rationale)	A (Adapt)
“Why not Platform Events instead of MuleSoft?"	"You’re asking if Platform Events alone could handle this integration”	3-sec pause	”Platform Events handle the pub/sub pattern well, but this scenario needs transformation and orchestration across 6 systems"	"Because MuleSoft provides centralized error handling, retry logic, and data mapping that Platform Events alone cannot"	"If the scenario had only 2 Salesforce-to-Salesforce integrations, I would absolutely use Platform Events instead"
"What if data volume triples in year 2?"	"You’re asking about scalability of my data model”	3-sec pause	”I would implement skinny tables and custom indexes on the high-volume objects now"	"Because retroactively adding LDV optimizations is more disruptive than designing for scale upfront"	"I would also add an archival strategy using Big Objects to keep the active dataset within performance thresholds”

Judge Probing Tactics — Quick Recognition

Tactic	What It Sounds Like	What They Test	Your Move
Direct challenge	”Why didn’t you use X?”	Can you defend with reasoning?	State trade-off, cite requirement
What-if scenario	”What if volume triples?”	Scalability thinking	Show evolution path
Depth probe	”Walk me through that OAuth flow”	Real understanding vs. bluffing	Go deep with specifics
Alternative push	”Have you considered Y?”	Awareness of alternatives	Compare/contrast both
Edge case	”What if integration fails at 2 AM?”	Failure scenario planning	Describe error handling + alerting
Requirement shift	”What if they add 5 countries?”	Adaptability	Assess impact across architecture
The hint	”Have you considered X?”	They think you should have	Treat as a gift, not an attack

Q&A Response Templates

When You Know the Answer

“I considered [alternative]. The trade-off is [X]. I chose [my approach] because [scenario-specific reason]. If [condition changed], I would switch to [alternative].”

When You Partially Know

“I’m not certain about the exact [detail], but architecturally I would address it by [reasonable strategy]. My approach would be to [specific action].”

When You Don’t Know

“I haven’t worked with that specific feature. Given the requirement, I would evaluate it against [criteria]. My architectural instinct says [reasoning], and in practice I would investigate [specific thing] before committing.”

Never bluff

Judges can sense when you are guessing. Honesty with intelligent reasoning always beats a confident wrong answer. Being realistic about your knowledge is a strength, not a weakness.

Common Trap Questions — Quick Defenses

Trap	How to Handle
False dichotomy — “So batch or streaming?”	Recognize the spectrum: “It depends on latency requirements. Near-real-time with 5-min polling balances…”
Scope creep — “What if they also need a mobile app?”	Assess impact: “That changes my architecture here… I’d recommend a phased approach where…”
Buzzword test — “Explain eventual consistency here”	Give scenario-specific explanation, not textbook definition
Governor limit probe — “What about the 50K SOQL limit?”	Show you know limits AND workarounds: “I’d implement [pattern] and monitor with…”
Cost challenge — “Isn’t that expensive?”	Tie to business value: “The middleware cost is offset by reduced custom integration maintenance and SLA guarantees”
Simpler way — “Couldn’t flows do that?”	Show you evaluated it: “I considered it. The limitation is [specific]. At this volume, [your choice] is more appropriate”

When to Stand Firm vs. Adapt

flowchart TD
    A["Judge Challenges\nYour Decision"] --> B{New information\nintroduced?}
    B -->|Yes| C{Fundamentally changes\narchitecture?}
    C -->|Yes| D["ADAPT\n'Given that constraint,\nI would revise to...'"]
    C -->|No| E["ACKNOWLEDGE + HOLD\n'Good point. My design\nhandles this because...'"]
    B -->|No| F{Clear justification\ntied to requirements?}
    F -->|Yes| G["STAND FIRM\nRestate trade-off and\nscenario-specific reason"]
    F -->|No| H["PIVOT\n'On reflection, X better\nserves this scenario...'"]

Danger Zone	Why It Fails
Always standing firm	Looks rigid — red flag for a consulting architect
Always adapting	Looks like guessing — red flag for a technical leader
Flip-flopping on same topic	Signals inability to make decisions
Getting defensive	Signals inability to handle client pressure

Confidence Quick-Ref

Do	Don’t
”I recommend…"	"I think maybe we could…"
"I chose this because…"	"This approach was chosen…”
Pause 3-5 sec before answering	Rush to fill silence
Correct mistakes openly	Stubbornly defend errors
Look at camera when speaking	Read from slides
Speak at measured pace	Speed up when nervous

Filler words

Minimize “um,” “uh,” “like,” “you know.” Record yourself practicing and count fillers. Deliberate pauses are always better than filler words.

Reverse-Engineered Use Cases

Use Case 1: The STAR-A Save

Situation: Judge asks “Your sharing model uses criteria-based sharing rules, but what happens when a new business unit is acquired and needs different access patterns?”

STAR-A response: “You’re asking about the scalability of my sharing model for acquisitions.” (pause) “I would extend the role hierarchy with a new branch for the acquired BU and add territory-based sharing if their sales model differs significantly. Because criteria-based sharing rules have a 300-rule limit per object, I designed the initial model with headroom — currently using 12 of 50. If the acquisition fundamentally changes the sharing paradigm, I would evaluate Apex-managed sharing as a fallback.”

Use Case 2: The Honest Gap Recovery

Situation: Judge asks “How does Shield Platform Encryption affect your SOQL queries on the encrypted fields?”

Response: “I’ll be honest — I haven’t implemented Shield Encryption at scale in production. My understanding is that deterministic encryption allows filtering but with performance implications, and probabilistic encryption does not support filtering. For this scenario, I would use deterministic encryption on the fields that require both encryption and query access, and probabilistic on fields that are display-only. I would validate this approach with Salesforce’s encryption documentation before implementation.”

Why it works: Honest about the gap, demonstrated reasoning process, showed a concrete next step.

Deep-Dive References

Review Board Presentation & Q&A Strategies — complete guide
Communication Best Practices — anti-patterns, body language
Communication Decision Guides — full decision flowcharts
Communication Quick Reference Overview

Sources

10 Exam Day Commandments

Sebastian Wagner’s (FlowRepublic) 10 rules for CTA Review Board day — memorize these:

#	Commandment	Why It Matters
1	Do NOT change your strategy	Changing your approach on exam day is “a recipe for failure, guaranteed.” Trust your preparation.
2	Keep cool	Managing stress is half the battle. Judges expect composure under pressure.
3	Read and solve fast	Read the scenario quickly, begin solving requirements on the fly during prep.
4	Solve for the scenario	Do NOT invent requirements that are not stated. Solve what is asked, nothing more.
5	Tell a story	Use a structured narrative that judges can easily follow and take notes on.
6	Be clear in communication	Clarity in diagrams, presenting, and answering questions. No ambiguity.
7	Accept mistakes, correct, move on	Assess the impact of the error, fix it, and continue. Do not dwell.
8	”I don’t know” is OK	Acceptable as long as it is not your default answer. Follow with reasoning.
9	Be concise	Answers must be Correct and Concise. Long answers open more attack surface.
10	Answer the question asked	Repeat or confirm the question first to ensure you heard correctly.

The CC Rule

Wagner’s golden standard: every answer should be CC — Correct and Concise. End with “Does that answer your question?” to confirm you addressed what the judge actually asked.