CTA Awareness common mistakes
CTA Awareness · Understand the traps and how to avoid them.
Designing a single-org solution that ignores the enterprise's multi-org or multi-tenant reality, then treating sharing rules as an afterthought once the data model is fixed.
Candidates default to the simplest single-org picture because it is easier to reason about, and they conflate 'one company' with 'one org'. The exam repeatedly tests whether you can justify a data-sharing boundary before you commit to objects and relationships.
What to do instead
Before drawing objects, write down the sharing boundary (who must see whose records) and the volume/security drivers. Decide multi-org vs single-org with explicit rationale, then model sharing mechanisms (OWD, role hierarchy, sharing rules, manual/Apex sharing) as first-class design elements, not cleanup.
Choosing the Salesforce integration pattern (REST callout, Platform Event, Change Data Capture, Bulk API) by habit or familiarity rather than by matching latency, volume, and direction to the pattern.
Candidates memorize pattern names but not the selection criteria, so a 2M-record nightly sync gets designed as synchronous REST callouts. The exam probes whether you can map a requirement to a pattern and explain the trade-off.
What to do instead
Build a decision table: latency (real-time vs batch), volume per transaction, direction (inbound/outbound), and coupling. State the pattern and the rejected alternatives with the reason. Practice articulating why Bulk API 2.0 beats REST for large batches and why Platform Events decouple producers from subscribers.
Treating a security model as 'profiles and permission sets' only, without addressing object-level, field-level, record-level, and session-level controls as a layered design.
Candidates learn the UI-driven pieces and stop there. Questions about least privilege, integration users, and data exposure require reasoning across multiple layers, which is easy to skip when you only rehearse permission-set mechanics.
What to do instead
For any scenario, enumerate all four layers explicitly: object permissions, field-level security, record access (OWD/sharing), and session/authentication (MFA, connected app policies). Explain how an integration user should be scoped differently from a human user.
Answering large-data-volume questions with 'add an index' or 'use SOQL efficiently' without quantifying selectivity, query selectivity thresholds, or the effect of skewed data and wide queries.
LDV is the domain where hand-wavy answers are most tempting, and candidates underestimate how much the exam rewards concrete reasoning about row counts, selectivity, and query plans.
What to do instead
Practice estimating: records per object, rows returned by a query, and whether a filter is selective. Know the difference between a full-table scan and an indexed lookup, and design skinny tables, custom indexes, and async processing (Batch Apex, Queueable) with stated limits in mind.
Skipping the deployment and lifecycle story-no discussion of environments, source control, CI, or how a change moves from dev to production-when asked to design a solution.
Candidates focus on the functional design and treat deployment as someone else's job. The exam expects architects to own the path to production, including metadata vs data deployment and rollback.
What to do instead
For every solution, add a deployment section: sandbox strategy, branching model, CI pipeline, test strategy, and rollback. Distinguish metadata deployment from data migration, and name the tooling (e.g., Salesforce CLI, change sets, DevOps Center) with a reason for the choice.
Presenting a design as a fait accompli to an architecture review board, with no options, no assumptions, and no stated trade-offs, then defending it personally when challenged.
Candidates treat review boards as a formality and prepare a pitch rather than a decision record. Reviewers test whether you can hold a position while remaining open, and candidates mistake pushback for failure.
What to do instead
Bring a decision record: context, options considered, recommendation, trade-offs, risks, and open questions. Separate 'what I recommend' from 'what I need from you'. Practice answering 'why not the other option?' in one sentence.
Confusing the CTA journey stages and answering process questions with technical content-or vice versa-because the candidate has not internalized what each stage evaluates.
The journey is a distinct domain, and candidates who skip it assume every question is a design question. The exam checks whether you understand the sequence, the artifacts expected at each stage, and how reviewers assess them.
What to do instead
Map the journey end to end and for each stage note the deliverable, the audience, and the failure signal. Rehearse the difference between a scenario review and a board review, and what 'architect-level' depth means at each.
Designing for the happy path and never naming the failure modes: what happens when an integration endpoint is down, a batch fails mid-run, or a governor limit is hit.
Candidates optimize for the correct flow because it is easier to describe. Resilience questions are where the exam separates architects from implementers, and candidates often have no rehearsed pattern for error handling and idempotency.
What to do instead
For every integration and async process, state the failure handling: retries with backoff, dead-letter/error logging, idempotency keys, checkpointing, and alerting. Practice describing what a partial failure looks like and how the system recovers without duplicate records.
Ignoring non-functional requirements-performance targets, scalability headroom, availability, and cost-until asked, then inventing numbers on the spot.
Candidates anchor on functional requirements because they are concrete. NFRs are usually implicit in the scenario, and candidates who do not extract them appear to design without constraints.
What to do instead
In every scenario, explicitly elicit and restate NFRs: expected volume, growth rate, latency targets, availability, and budget. Tie design choices to those numbers. If a number is unknown, state the assumption and how you would validate it.
Describing platform capabilities in generic marketing terms ('scalable', 'secure', 'best practice') instead of naming the specific mechanism, limit, or configuration that makes the design work.
Candidates fall back on buzzwords when they are unsure of the mechanism. The exam rewards specificity, and vague answers read as lack of depth even when the underlying instinct is right.
What to do instead
Replace every adjective with a mechanism: not 'secure' but 'connected app with IP restrictions and a scoped integration user'; not 'scalable' but 'Bulk API 2.0 with batches sized to stay under limits'. If you cannot name the mechanism, flag it as a knowledge gap rather than bluffing.