Salesforce Business Analyst common mistakes
Salesforce Business Analyst · Understand the traps and how to avoid them.
In a discovery scenario, the candidate's first move is to propose Salesforce features (custom objects, validation rules, Flow) rather than asking how the work is done today, who does it, and what the pain costs the business.
Platform familiarity feels like expertise, and naming a feature early signals competence; the candidate conflates the business analyst role with the administrator or architect role.
What to do instead
In discovery questions, answer with elicitation first: current-state process, actors, volume/frequency, workarounds, and the measurable business problem. Park all feature talk in a separate 'solution ideas' note and only revisit it once the problem statement is agreed with the business.
The candidate builds the requirement set from one or two accessible contacts (usually the sponsor or the requesting manager) and never interviews the people who actually execute the process, support it, or consume its output.
The loudest or most available stakeholder is easy to schedule and appears authoritative, so coverage feels complete when it is not; time pressure rewards the path of least resistance.
What to do instead
Before closing discovery, produce a stakeholder map that classifies each group by role (decision maker, subject matter expert, end user, support/ops, downstream consumer) and by influence/interest, then confirm explicitly that each role has been represented and record who was deliberately excluded and why.
The candidate records a stated request ('we need a new field on the account', 'we need an approval step') as the requirement verbatim, without asking what decision or outcome depends on it.
Requirements are treated as a transcription exercise, and stakeholders naturally present solutions rather than problems, so the candidate echoes the solution back as if it were the need.
What to do instead
Convert every stated want into a problem statement and a business outcome before it enters the backlog: ask what happens today without it, what decision it enables, and what would change if it were solved a different way. Log the original want alongside the derived need so traceability to the stakeholder's words is preserved.
The candidate starts work without agreeing who decides, who must be consulted, and who is merely informed, then is surprised when a group that was never engaged blocks sign-off late in the cycle.
Participants assume roles are self-evident from job titles, and building a RACI or decision-rights table feels like bureaucracy compared with getting on with the analysis.
What to do instead
At kickoff, publish a lightweight RACI covering requirement approval, prioritisation, design decisions, and UAT sign-off, and state the escalation path. When a scenario introduces a stakeholder who was 'not consulted', the answer should be a governance gap to fix, not a communication task to schedule.
When two stakeholder groups want conflicting things, the candidate either quietly picks one, or immediately forwards the disagreement to the sponsor instead of facilitating a resolution and recording the outcome.
Conflict is uncomfortable and escalation feels safe and decisive; documenting a contested decision also creates accountability that the candidate would rather avoid.
What to do instead
Facilitate a joint session with both parties against shared criteria (business value, effort, risk, compliance), drive to a documented decision with the named decision owner, and record the rejected option and rationale. Escalate only when the decision genuinely sits above the participants' authority, and say so explicitly.
Requirements are written as build instructions ('create a formula field that...', 'add a screen flow with three steps') instead of as the capability and outcome the business needs.
The candidate is used to configuration work and believes specificity demonstrates rigour; prescriptive wording also feels easier to test than an abstract business statement.
What to do instead
Split the artefact into business requirements (the need and the outcome, solution-agnostic) and solution design (the 'how', owned jointly with the admin or architect). If a requirement contains a Salesforce object, field, or automation name, it belongs in the design section, not the requirement statement.
Requirements are accepted with no acceptance criteria, or with unverifiable ones such as 'must be user-friendly', 'should be fast', or 'reports must be accurate'.
Acceptance criteria are assumed to be a QA or developer responsibility, and writing them forces the candidate to resolve ambiguity that the stakeholder left open.
What to do instead
Attach at least one verifiable criterion to every requirement, in Given/When/Then form or as an explicit threshold (for example a stated response time, record volume, or field-level accuracy rule). Before sign-off, ask of each criterion: could two people independently disagree on whether it passed? If yes, rewrite it.
Every requirement is carried as equally mandatory, nothing is baselined or signed off, and the candidate renegotiates scope continuously instead of managing it.
Dropping or deferring an item risks disappointing a stakeholder, so the candidate avoids ranking; and an unsigned, unprioritised list feels flexible rather than unstable.
What to do instead
Run an explicit prioritisation pass with the business owner using an agreed scheme (MoSCoW or value versus effort), record the rationale for each tier, then baseline the approved set and route later changes through a change log rather than silently absorbing them.
The candidate treats the analysis process as a one-way sequence of phases, produces documents that are never linked to each other, and does not reopen discovery when a late finding contradicts an earlier assumption.
Exam scenarios are read as phase-labelled questions, so the candidate memorises the order of activities instead of the feedback loops and traceability that connect them.
What to do instead
Maintain a traceability chain from business objective to requirement to design element to test case, and in scenario questions check whether new information invalidates an earlier artefact. An answer that revisits an earlier phase with justification is usually stronger than one that pushes forward on a broken assumption.
Scope and design changes arrive informally and are absorbed without assessment, and the engagement ends with no agreed measure of whether the delivered solution solved the original problem.
Change control and benefits measurement sit at the edges of the project where pressure is lowest, and the candidate treats 'go live' as the finish line.
What to do instead
Apply a defined change process to every request after baseline (impact on scope, schedule, cost, risk; decision by the named owner), and define success measures and a post-implementation review point during discovery, not after deployment, so the requirement set can be tested against the original business outcome.