Salesforce Certified Business Analyst Study Guide

Domain 1: Customer Discovery

Key concepts you must know · 110 practice questions

A business analyst starts from strategy, not from Salesforce. Establish the business goals, the initiatives meant to achieve them, and the measures of success before discussing any feature - a requirement that cannot be traced to a business objective is a request, not a requirement.
Learn the implementation lifecycle phases and what a BA does in each: discovery and definition, design, build, test, deploy, and adopt. The BA is heaviest at the front and returns at user acceptance and adoption.
Waterfall delivers in sequential phases with requirements fixed early; agile delivers iteratively with a prioritised backlog and requirements refined as it goes. Salesforce projects are commonly hybrid, and the exam expects you to recognise which is described rather than to advocate one.
Discovering the current state means documenting how work is done now - the actual process, the people, the systems and the pain points - before designing anything. Skipping it produces solutions that automate a broken process faster.
Distinguish a problem from a symptom and from a proposed solution. "Reps take too long to quote" is a symptom, "approval routing requires three manual emails" is a problem, and "build a flow" is a proposed solution. Asking why repeatedly is how you get from the first to the second.
Analyse the existing Salesforce environment before proposing change: which objects and fields are actually used, what automation already runs, what is customised, and what technical debt exists. Setup, the object manager and the optimizer report are where that evidence comes from.
Assess data quality early, because it shapes what is feasible: duplicate records, empty required fields, inconsistent picklist values and unused custom fields all constrain reporting and automation, and they surface in discovery rather than at go-live if you look.
Understand the org's history to interpret what you find. A field nobody populates, an automation nobody can explain, and a report everybody exports are all evidence about the real process rather than the documented one.
Know the difference between capabilities the org already has and ones it would need to license or build, because a discovery that recommends unavailable functionality wastes the stakeholders' time and the project's credibility.
Frame discovery findings so they can be acted on: the current state, the specific problems, their business impact quantified where possible, and the opportunities - not a narrative of every conversation you had.

Domain 2: Collaboration with Stakeholders

Key concepts you must know · 149 practice questions

Identify stakeholders systematically rather than by who is loudest: the sponsor who funds and decides, the process owners accountable for the work, the end users who live with the result, the technical team who build it, and anyone in compliance or security with a veto.
Map stakeholders by influence and interest so you engage each appropriately - manage the high-influence, high-interest group closely, keep the high-influence low-interest group satisfied, and inform the rest. Treating everyone identically is how a project loses a sponsor.
Build relationships before you need them. A stakeholder who trusts the BA raises problems early; one who does not raises them at user acceptance testing, when changing anything is most expensive.
Plan discovery activities to fit the audience and the question: interviews for depth and sensitive detail, workshops for cross-functional decisions and shared understanding, surveys for breadth across many users, observation for what people actually do rather than what they say.
Observation and job shadowing reveal the workarounds nobody reports - the spreadsheet kept alongside the system, the fields filled with placeholder values. Those workarounds are usually the most valuable finding in discovery.
Run a workshop deliberately: agenda and objective circulated in advance, the right people in the room, a facilitator who is not also the decision maker, and documented decisions and actions at the end. A workshop without a stated decision to reach becomes a status meeting.
Use open questions to explore and closed questions to confirm, and avoid leading questions that put the answer in the stakeholder's mouth. Ask what happens when things go wrong, not just how the process works when it goes right.
Move from current state to future state as an explicit, agreed step: present the current state back for confirmation, identify the gaps and their impact, then design a future state stakeholders have signed up to rather than one you have inferred.
Ground future-state options in what Salesforce actually does. Knowing the platform is part of the BA role here: which requirements are met by configuration, which need custom development, and which are better solved by changing the process instead.
Prefer declarative solutions and question requirements that force customisation, because configuration is cheaper to build, safer to change and easier to support. "Can we achieve the outcome a supported way?" is a legitimate and expected BA question.
Manage competing priorities by making the trade-off visible rather than deciding privately: show what each option costs in time and scope, who benefits, and what is displaced. The decision belongs to the sponsor; the clarity is the BA's job.
Handle conflict between stakeholders by returning to the business objective and the evidence. Disagreements about a solution are usually disagreements about a problem definition that was never settled.
Obtain sign-off explicitly and record it: who agreed, to what version, and when. An informal nod in a corridor is not sign-off, and the absence of a recorded decision is what turns a change request into an argument.
Communicate at the right altitude for the audience - outcomes and risk for executives, process detail for process owners, and precise acceptance criteria for the build team. The same content at the wrong level loses the room.

Domain 3: Business Process Mapping

Key concepts you must know · 78 practice questions

Define the scope of a process map before drawing it: where the process starts, where it ends, and which participants are included. An unbounded map grows until it is unreadable and decides nothing.
Map the current state first so the future state has something to be compared against, and so the improvement can be described concretely - fewer handoffs, fewer manual steps, fewer places the work can stall.
Use consistent notation so a map means the same thing to everyone: a rectangle for an activity, a diamond for a decision, an oval for start and end, and arrows for flow. BPMN is the common formal standard.
Swimlanes assign each step to the role or system that performs it, which is what makes handoffs visible. Handoffs are where work waits, gets lost and gets rekeyed, so they are where most improvement is found.
Capture decision points properly, with the criteria and every branch including the exception path. A map with only the happy path hides exactly the cases that make the process expensive.
A capability model describes what the business does, and a process map describes how it does it. Use the capability view to frame scope at the strategic level and the process map for the detail.
Value stream mapping adds time and value to the picture, distinguishing time spent doing work from time spent waiting. Waiting usually dominates, which is why automation of a single step often changes the total very little.
Validate a process map with the people who do the work, not only with their managers. The documented process and the real process diverge, and the BA's value is in surfacing that difference.
Keep the map at a consistent level of detail. Mixing a whole department in one box with three boxes for a single form field makes the map impossible to reason about.
Use the map as an analysis tool rather than a deliverable: mark the pain points, the manual steps, the rework loops and the delays, and let that annotated map drive the requirements that follow.

Domain 4: Requirements

Key concepts you must know · 117 practice questions

A requirement states what the business needs, independent of how it will be built. As soon as a requirement names a Salesforce feature it has become a design decision, which narrows the options before they have been evaluated.
Distinguish the types: business requirements express the objective, stakeholder requirements express what a group needs, functional requirements express what the solution must do, and non-functional requirements cover performance, security, usability and compliance.
Non-functional requirements are the ones most often missed and the most expensive to retrofit - response time, data retention, audit, accessibility, and who must not be able to see what.
Elicit requirements with the technique that suits the source, and expect to combine several. What a stakeholder says they need, what the process map shows, and what the data reveals will not agree, and reconciling them is the analysis.
Write requirements so they are testable: specific, unambiguous, and stated in a way that someone can later demonstrate has been met. "The system should be fast" cannot be accepted or rejected.
Validate requirements against the business objective - does meeting this actually advance the goal - and verify them with stakeholders - is this what you meant. Both steps are needed and they are different questions.
Prioritise explicitly with a technique the stakeholders understand, such as MoSCoW - must, should, could, will not have this time - or value against effort. A backlog where everything is critical has not been prioritised.
Prioritisation is a business decision informed by the BA, not made by them. Present value, effort, risk and dependency; let the sponsor or product owner choose.
Maintain traceability from business objective through requirement to user story to test case, so you can answer why a piece of work exists and what breaks if it is dropped. It is also what makes scope changes assessable rather than emotional.
Identify dependencies and constraints alongside the requirements: sequencing between items, reliance on another team or system, and the fixed limits of budget, deadline, licensing and platform.
Watch for gold plating and scope creep, which arrive differently. Gold plating is the team adding unrequested polish; scope creep is requirements accumulating without a corresponding decision about time or budget. Both are managed by traceability and a change process.
Document requirements in a form the audience will actually use and keep current. A requirements document that is out of date by the second sprint is worse than a shorter one that is maintained.

Domain 5: User Stories

Key concepts you must know · 117 practice questions

A user story states who wants something, what they want and why: as a role, I want a capability, so that a benefit. The "so that" is the part that gets dropped and the part that lets the team propose a better solution.
Write stories from the user's perspective, not the system's. "As a sales manager I want to see my team's open pipeline by stage so that I can spot deals that have stalled" is a story; "as a user I want a report" is a task.
Use INVEST to judge a story: independent, negotiable, valuable, estimable, small and testable. A story failing several of those is usually an epic that has not been split.
An epic is a large body of work spanning more than an iteration and is split into stories. Split along user value - by workflow step, by user role, by simple case before complex case - not by technical layer, so each story still delivers something usable.
Acceptance criteria define done for a story: the specific, testable conditions the solution must satisfy. They are written before development, agreed with the team, and they become the basis of the test cases.
Given-when-then is the common format - given some context, when an action occurs, then an outcome follows - and it works well because it forces the precondition and the observable result to be stated rather than assumed.
Cover the negative and edge cases in acceptance criteria, not just the happy path: what happens with missing data, insufficient permissions, or a value outside the expected range.
Keep acceptance criteria free of implementation detail. They say what must be true, not which field, flow or validation rule delivers it, which leaves the team free to find the simplest supported way.
The definition of done is a team-wide standard applying to every story - coded, tested, documented, deployed to the right environment - and is distinct from acceptance criteria, which are specific to one story.
Groom and refine the backlog continuously so upcoming stories are ready before the team commits to them: clarified, estimated, dependencies known, and small enough to finish within the iteration.
Story points estimate relative size and complexity rather than hours, which is why they are estimated by the team who will do the work and are not comparable between teams.
Keep the story as the record of the conversation rather than a substitute for it. The story is a placeholder that carries enough detail for the team to build and for the BA to verify.

Domain 6: User Acceptance

Key concepts you must know · 78 practice questions

User acceptance testing confirms the solution meets the business need in real conditions, which is a different question from whether it works technically. Business users run it, not the build team, because the point is validation rather than verification.
Plan UAT before build finishes: who tests, in which environment, against which scenarios, over what period, and how defects are raised, triaged and retested. UAT arranged the week it starts always slips.
Build UAT scenarios from the acceptance criteria and from real business processes end to end, using representative data. A test that only exercises one screen at a time misses the handoffs that break.
Use a full sandbox or a partial copy with realistic data for UAT, since testing against invented data hides the duplicate records, missing values and volume effects that appear immediately in production.
Support the development team during build by staying available: clarifying acceptance criteria, answering questions about intent, and reviewing increments as they are demonstrated rather than only at the end.
Triage UAT defects into genuine defects, misunderstandings of the requirement, and new requests. Only the first is a fix; the second is a clarification and the third is a change that goes to the backlog and the prioritisation conversation.
Track defects with enough detail to reproduce them - steps, expected result, actual result, user and data used - because a defect nobody can reproduce consumes more time than one clearly described.
Define acceptance and exit criteria for UAT in advance: which severities must be resolved before go-live and which can be deferred. Otherwise the decision to go live becomes a negotiation under time pressure.
Obtain and record formal sign-off from the business owner at the end of UAT. It is the point at which the business accepts the solution, and it must be an explicit decision by a named person.
Plan the release beyond the deployment itself: training tailored to each role, communications, a support model for the first weeks, and a rollback position if something material fails.
Adoption is part of the BA's remit, not someone else's problem afterwards. Measure whether the solution is actually used - login and feature usage, the business metric the project was meant to move - and feed what you find back into the backlog.
Close the loop by evaluating whether the business objective was met, since that is what the project was for. A delivered solution that did not change the measure is a finding worth acting on rather than a project to declare successful and forget.

Salesforce Certified Business Analyst exam tips

Collaboration with Stakeholders is the largest section at 23%, and Requirements and User Stories are 18% each. Together those three are around 59% of the exam, so the analysis and communication work outweighs the process-mapping notation many candidates over-study.
Answer as a business analyst, not as an administrator. When an option describes configuring something and another describes clarifying the need or confirming with a stakeholder, the BA answer is usually the latter - the exam tests judgement about process, not clicks.
Keep requirements separate from solutions. A requirement says what the business needs; naming a Salesforce feature makes it a design decision. Several questions turn on spotting a solution disguised as a requirement.
Know the user story anatomy cold: as a role, I want a capability, so that a benefit, plus testable acceptance criteria in given-when-then form. Acceptance criteria are per story; the definition of done is per team.
For any stakeholder conflict or competing-priority scenario, the expected behaviour is to make the trade-off visible and let the sponsor or product owner decide, then record the decision. The BA facilitates the decision rather than making it.
For process mapping, remember that swimlanes exist to expose handoffs, and that handoffs are where work waits and gets rekeyed. Always map the current state before the future state.
In UAT scenarios, distinguish a defect from a misunderstood requirement from a new request. Only the first is fixed in the current scope; the third goes to the backlog and prioritisation.
The exam is scenario-based and the wrong answers are usually plausible but premature - building before validating, deciding before consulting, or documenting a solution before the problem is agreed.

Study guide FAQ

What is the format of the Salesforce Business Analyst exam?

The exam is 60 multiple-choice questions plus up to five unscored questions, in 105 minutes, with a passing score of 72%. The registration fee is US$200 plus applicable taxes, with a paid retake if needed. There are no prerequisites.

Do I need to be a Salesforce Administrator first?

It is not a prerequisite, but platform knowledge helps a great deal. Several published objectives ask you to judge how Salesforce features and best practices affect solution options, which means knowing what can be achieved declaratively and what would require custom development. Many candidates take the Administrator credential first for that reason.

Which section carries the most weight?

Collaboration with Stakeholders at 23%, followed by Requirements and User Stories at 18% each. Customer Discovery is 17%, and Business Process Mapping and User Acceptance are 12% each. Preparation weighted towards stakeholder work, requirements and stories covers around 59% of the exam.

How technical is this exam?

Less technical than the Administrator exam and more about analysis judgement. You are not asked to configure security models or build flows, but you are expected to understand Salesforce well enough to know whether a requirement is achievable through configuration, and to recognise when changing the process is a better answer than customising the platform.

What is the difference between a requirement and a user story?

A requirement states what the business needs and is usually documented for the whole solution and traced back to a business objective. A user story is a small, user-perspective slice of that need, sized to be delivered in an iteration, written as "as a role, I want a capability, so that a benefit" and accompanied by testable acceptance criteria. One requirement typically becomes several stories.

Related Salesforce resources

Test yourself: 649 Salesforce Certified Business Analyst practice questions