This is a deep study guide for the Salesforce Certified Business Analyst exam. It covers every section of the exam outline with explanations, process diagrams, quick-reference tables, templates, a worked example and practice questions with answers and explanations.
Updated for 2026: written for the current outline and delivery through Trailhead Academy and Pearson VUE. The Salesforce Administrator prerequisite was removed in 2023, so you can take this exam as your first Salesforce certification, though Salesforce platform knowledge still matters on many questions.
| Section | Weight | Approx. questions |
|---|---|---|
| Customer Discovery | 17% | ~10 |
| Collaboration with Stakeholders | 23% | ~14 |
| Business Process Mapping | 12% | ~7 |
| Requirements | 18% | ~11 |
| User Stories | 18% | ~11 |
| Development Support and User Acceptance | 12% | ~7 |
| Exam fact | Detail |
|---|---|
| Official name | Salesforce Certified Business Analyst |
| Format | 60 scored multiple-choice and multiple-select questions, plus up to 5 unscored |
| Time | 105 minutes |
| Passing score | 72% (about 44 of 60) |
| Fee | $200 USD, retake $100, plus applicable taxes |
| Prerequisites | None since May 2, 2023 (Administrator was previously required) |
| Delivery | Onsite or online proctored through Trailhead Academy and Pearson VUE |
| Official resources | Exam FAQ and guide, credential page |
Collaboration is the largest section; requirements and user stories together are 36%.
Contents
- Who this certification is for
- What changed for 2026
- How to use this guide
- The BA lifecycle on a Salesforce project
- Customer Discovery (17%)
- Collaboration with Stakeholders (23%)
- Business Process Mapping (12%)
- Requirements (18%)
- User Stories (18%)
- Development Support and User Acceptance (12%)
- Deep dive: Salesforce features every BA should recognize
- Deep dive: agile vs. waterfall for BAs
- Deep dive: writing requirements for AI and Agentforce features
- Worked example: from request to release
- Hands-on checklist
- Common exam traps
- Flashcard terms
- Mixed practice exam: 10 more questions
- Quick-reference cheat sheet
- Frequently asked questions
- Related study guides
Who this certification is for
The exam is for people who sit between the business and the Salesforce team: business analysts, functional consultants, product owners, admins who run discovery, and project managers who write requirements. Salesforce describes the target candidate as someone with experience in Salesforce projects who elicits requirements, maps processes, writes user stories and supports delivery and user acceptance testing.
The exam is scenario-heavy. Most questions describe a project situation and ask what a business analyst should do first, next or best. Knowing BA techniques matters as much as knowing Salesforce features, and many questions reward the answer that involves the right stakeholders, confirms understanding and documents decisions.
What changed for 2026
- No prerequisite. The Administrator requirement was removed on May 2, 2023, and that's still the case.
- Same six sections. The outline continues to cover discovery, collaboration, process mapping, requirements, user stories and development support.
- AI in the BA toolkit. Salesforce projects increasingly include Agentforce and AI features. Expect discovery and requirements scenarios where the "user" is partly an AI agent, and where data quality and trust requirements matter. The BA techniques are the same.
- Registration moved to Trailhead Academy, with Pearson VUE delivery.
How to use this guide
- Read each section and its tables, then do the matching exercise from the hands-on list.
- Answer the practice questions and pay close attention to "first" and "best" wording.
- Practice drawing one real process as a swim lane diagram and writing five user stories with acceptance criteria.
- Finish with the worked example and mixed questions, then take a timed practice exam: 60 questions in 105 minutes.
A five-week plan, about 5 hours per week.
The BA lifecycle on a Salesforce project
The six sections map to the order of work on a typical project:
- Customer discovery: understand the organization, its goals, current state and pain points.
- Collaboration with stakeholders: identify stakeholders, plan engagement, run workshops, manage conflicts and communicate.
- Business process mapping: document current and future processes.
- Requirements: elicit, analyze, prioritize and manage requirements and their traceability.
- User stories: write stories and acceptance criteria the delivery team can build and test.
- Development support and user acceptance: support the build, plan and run UAT, and help with release and adoption.
Real projects loop through these steps repeatedly, especially in agile delivery, but the exam often expects you to recognize where a scenario sits in this sequence.
The six sections in the order you usually perform them.
Customer Discovery (17%)
Discovery is about understanding the business before proposing solutions.
Understand the organization. Learn the company's mission, strategy, industry, business model, organizational structure, key metrics and the reason for the project. Review existing documentation: org charts, process documents, current Salesforce configuration, reports and previous project artifacts.
Current state analysis. Document how work is done today, which systems are used, where data lives, and what's painful. In a Salesforce org, that includes reviewing the existing data model, automation, integrations, user adoption and technical debt.
Elicitation techniques.
| Technique | Best for |
|---|---|
| Interviews | Deep understanding from individual stakeholders |
| Workshops | Building shared understanding and resolving differences with a group |
| Observation (job shadowing) | Seeing how work is really done, including workarounds |
| Surveys and questionnaires | Gathering input from many users quickly |
| Document analysis | Learning from existing processes, policies and reports |
| Focus groups | Gathering opinions on a product or idea |
| Prototyping | Clarifying requirements by showing something tangible |
| System analysis | Understanding current Salesforce configuration and data |
Questioning. Use open-ended questions to explore, closed questions to confirm, and "why" questions (such as the five whys) to reach root causes. Ask about outcomes, not just features: "What problem does this solve?" and "How will we measure success?"
Defining the problem and success. A clear problem statement and measurable success criteria (KPIs) keep the project focused. Good discovery identifies the business value of each change.
Gap analysis. Compare the current state with the desired future state to identify gaps that the solution must close.
Salesforce-specific discovery. Understand what Salesforce can do out of the box before proposing custom work. A BA who knows standard features (lead conversion, opportunity stages, case management, approval processes, Flow) can steer toward configuration over customization.
What discovery produces before anyone builds.
Practice questions: Customer Discovery
Question 1. A BA is starting a project to improve a sales team's opportunity management. What should the BA do first?
- A. Configure new opportunity stages in a sandbox
- B. Understand the business goals and current sales process
- C. Write user stories for new fields
- D. Schedule UAT
Answer: B. Discovery starts with goals and the current state before solutions.
Question 2. Users say the case process is fine in interviews, but managers report long resolution times. Which technique would best reveal what's happening?
- A. Observation of agents working cases
- B. A survey of executives
- C. Writing acceptance criteria
- D. Deploying a change set
Answer: A. Observation reveals workarounds that users don't mention in interviews.
Question 3. A stakeholder asks for a new custom object to track partner deals. What should the BA do before agreeing?
- A. Understand the underlying need and check whether standard features (such as opportunities with a partner field or record type) meet it
- B. Immediately create the object
- C. Escalate to the CEO
- D. Reject the request
Answer: A. Understand the need and favor standard functionality.
Question 4. Which technique gathers input from 500 field sales reps across regions most efficiently?
- A. Survey
- B. One-on-one interviews with each rep
- C. Job shadowing every rep
- D. Prototyping
Answer: A. Surveys scale to large groups.
Question 5. What's the purpose of asking "why" repeatedly about a stated problem?
- A. To find the root cause rather than treating symptoms
- B. To delay the project
- C. To test the stakeholder's patience
- D. To write test scripts
Answer: A. The five whys technique uncovers root causes.
Question 6. Which two items help define project success during discovery? (Choose two.)
- A. Measurable KPIs tied to business goals
- B. A clear problem statement
- C. The color of the Lightning theme
- D. The number of sandboxes
Answer: A and B. Problem statements and KPIs anchor scope and success.
Collaboration with Stakeholders (23%)
The largest section. It covers identifying stakeholders, planning engagement, facilitating sessions, communicating and managing conflict and change.
Stakeholder identification and analysis. Identify everyone affected by or influencing the project: executive sponsors, business owners, end users, IT, admins, developers, compliance, partners and customers. Analyze each stakeholder's power (influence) and interest:
| Quadrant | Strategy |
|---|---|
| High power, high interest | Manage closely: involve in decisions |
| High power, low interest | Keep satisfied: brief updates, escalate key decisions |
| Low power, high interest | Keep informed: regular communication, gather input |
| Low power, low interest | Monitor: minimal communication |
RACI. A RACI matrix clarifies who is Responsible (does the work), Accountable (owns the decision, one person), Consulted (gives input) and Informed (kept up to date) for each deliverable or decision.
Communication plan. Define what's communicated, to whom, how often, in which channel and by whom. Executives want outcomes and risks; end users want what changes for them and when.
Facilitation. Plan workshops with a clear agenda, objectives, the right attendees, pre-reads and a facilitator. Use timeboxing, parking lots for off-topic items, and summaries of decisions and action items. Follow up with notes.
Conflict resolution. When stakeholders disagree, bring the discussion back to business goals and data, facilitate trade-offs, and escalate to the accountable decision maker when needed. Avoid choosing sides based on seniority alone.
Change management and adoption. Plan for training, communication, champions and feedback loops. Adoption is a project outcome, not an afterthought.
Working in agile teams. BAs often work with a product owner (who owns the backlog and priorities), a scrum master and developers. Know agile ceremonies: backlog refinement, sprint planning, daily stand-up, sprint review (demo) and retrospective.
Analyze stakeholders, then plan how you engage each group.
Practice questions: Collaboration with Stakeholders
Question 1. A VP has high influence over the project but little interest in details. How should the BA engage the VP?
- A. Keep satisfied with concise updates and involve them in key decisions
- B. Invite them to every daily stand-up
- C. Ignore them until go-live
- D. Send detailed technical specifications daily
Answer: A. High power, low interest: keep satisfied.
Question 2. Sales and marketing disagree on the lead qualification criteria. What should the BA do?
- A. Facilitate a session focused on shared business goals and data, then escalate to the accountable decision maker if needed
- B. Choose the sales team's criteria because sales generates revenue
- C. Implement both sets of criteria
- D. Postpone the decision indefinitely
Answer: A. Facilitate based on goals; escalate to the accountable owner.
Question 3. In a RACI, how many people should be Accountable for a decision?
- A. One
- B. Everyone on the team
- C. None
- D. At least three
Answer: A. One person is accountable for each decision or deliverable.
Question 4. A workshop keeps drifting into topics outside its objective. What technique helps?
- A. A parking lot for off-topic items
- B. Ending the workshop
- C. Removing attendees
- D. Writing code during the session
Answer: A. Parking lots capture issues for later without derailing the session.
Question 5. Who owns the prioritization of the product backlog in Scrum?
- A. Product owner
- B. Scrum master
- C. Developer
- D. QA tester
Answer: A. The product owner prioritizes the backlog.
Question 6. End users are anxious about a new Service Console rollout. Which two actions support adoption? (Choose two.)
- A. Identify champions within the support team
- B. Provide role-based training before go-live
- C. Hide the release date from users
- D. Remove all old reports without notice
Answer: A and B. Champions and training build adoption.
Question 7. After a requirements workshop, what should the BA do?
- A. Send a summary of decisions, open questions and action items to attendees
- B. Start building in production
- C. Wait for stakeholders to remember
- D. Delete the notes
Answer: A. Documenting outcomes keeps everyone aligned.
Business Process Mapping (12%)
Why map processes. Process maps make work visible: steps, handoffs, decisions, systems and delays. They help find inefficiencies and agree on the future state before building.
Current state vs. future state. Map the current state ("as is") to understand today's process and pain points, then the future state ("to be") to show how work will happen with the solution.
Levels of detail.
| Level | Shows |
|---|---|
| Level 0 / value stream | High-level end-to-end flow (such as lead to cash) |
| Level 1 | Major process steps within a stage |
| Level 2 and below | Detailed tasks, decisions and system interactions |
Notation. Swim lane diagrams show who does each step (roles or systems in lanes). Common symbols: start and end events, tasks (rectangles), decisions (diamonds), arrows for flow, and documents or systems. BPMN is a standard notation; UPN (Universal Process Notation) is used by some Salesforce-ecosystem tools. Keep diagrams consistent and readable for the audience.
Analyzing processes. Look for bottlenecks, unnecessary handoffs, rework loops, manual data entry, approvals that add no value, and steps that can be automated with Salesforce (Flow, approval processes, assignment rules).
Capturing the "why". Annotate maps with rules, exceptions, metrics and pain points, and link steps to requirements.
A simple swim lane shows who does what, where decisions happen and what can be automated.
Practice questions: Business Process Mapping
Question 1. Which diagram best shows which role performs each step of a process?
- A. Swim lane diagram
- B. Pie chart
- C. Entity relationship diagram
- D. Gantt chart
Answer: A. Swim lanes separate steps by role or system.
Question 2. A BA wants to understand today's process before designing improvements. What should be mapped?
- A. Current state
- B. Future state only
- C. Test scripts
- D. The deployment plan
Answer: A. Map the as-is process first.
Question 3. A process map shows an order bouncing between finance and sales three times before approval. What does this indicate?
- A. A rework loop or unclear handoff that should be analyzed
- B. A well-designed process
- C. A need for more report types
- D. A sandbox refresh issue
Answer: A. Repeated handoffs signal inefficiency.
Question 4. Executives want to see the end-to-end lead-to-cash flow on one page. What level of map fits?
- A. High-level (level 0 or value stream)
- B. Detailed task level with every field
- C. A data dictionary
- D. A user story
Answer: A. Executives need the high-level view.
Question 5. Which symbol typically represents a decision in a process map?
- A. Diamond
- B. Circle
- C. Rectangle
- D. Cylinder
Answer: A. Decisions are diamonds; tasks are rectangles.
Requirements (18%)
Types of requirements.
| Type | Describes | Example |
|---|---|---|
| Business requirement | What the organization needs to achieve | Reduce case resolution time by 20% |
| Stakeholder or user requirement | What a group of users needs | Agents need to see customer order history on the case |
| Functional requirement | What the system must do | The system must display the last five orders on the case page |
| Non-functional requirement | How the system must perform | The case page must load in under three seconds; data must be encrypted |
| Transition requirement | What's needed to move to the new state | Migrate open cases; train agents |
Good requirements are clear, concise, testable, feasible, necessary and traceable. Avoid ambiguous words like "fast," "easy" or "user-friendly" without measurable criteria.
Prioritization. MoSCoW groups requirements as Must have, Should have, Could have and Won't have (this time). Other approaches include value vs. effort scoring and ranking by business value. Prioritize with stakeholders, not alone.
Traceability. A requirements traceability matrix links each requirement to its source, business objective, user stories, design, test cases and status. It helps with impact analysis when requirements change and ensures nothing is missed in testing.
Managing change. Requirements change. Use a change control process: document the change, analyze impact (scope, time, cost, other requirements), get approval from the accountable stakeholder, then update the backlog and traceability.
Fit-gap analysis. Compare requirements to standard Salesforce capabilities: fits use configuration, gaps may need Flow, AppExchange apps or custom development. Prefer declarative solutions where they meet the need.
Documentation. Requirements may be captured in a requirements document, a backlog of user stories, a data dictionary, a process map or a combination. Store them where the team can find and update them.
From need to traceable, prioritized requirement.
Practice questions: Requirements
Question 1. "The opportunity page must load within three seconds for 95% of users." What type of requirement is this?
- A. Non-functional
- B. Business
- C. Transition
- D. Functional
Answer: A. Performance requirements describe how the system performs.
Question 2. A stakeholder requests a new feature mid-sprint. What should the BA do?
- A. Follow the change control process: document, analyze impact and get prioritization from the product owner
- B. Add it to the sprint immediately
- C. Reject it without discussion
- D. Build it secretly
Answer: A. Changes go through impact analysis and prioritization.
Question 3. Which tool links requirements to user stories and test cases?
- A. Requirements traceability matrix
- B. Stakeholder grid
- C. Report subscription
- D. Swim lane diagram
Answer: A. Traceability matrices connect requirements across the lifecycle.
Question 4. In MoSCoW, what does "W" mean?
- A. Won't have this time
- B. Wish list
- C. Workflow
- D. Weekly
Answer: A. Won't have (this time) documents agreed exclusions.
Question 5. Which requirement is most testable?
- A. "The system should be easy to use"
- B. "When a case is closed, the system sends a satisfaction survey email to the contact within 15 minutes"
- C. "Reports should be fast"
- D. "Users should like the new layout"
Answer: B. It's specific and measurable.
Question 6. A requirement can be met with standard Salesforce functionality or with custom code. What should the BA generally recommend?
- A. The standard or declarative option, if it meets the requirement
- B. Custom code, because it's more flexible
- C. An external system
- D. Whatever the developer prefers
Answer: A. Prefer configuration over customization when it meets the need.
User Stories (18%)
Format. A user story describes functionality from the user's perspective:
As a [role], I want [capability] so that [benefit].
Acceptance criteria. Each story needs acceptance criteria that define when it's done. A common format is Given / When / Then:
- Given a case with priority High,
- When the case is created,
- Then it's assigned to the Tier 2 queue and the account owner is notified.
INVEST. Good stories are Independent, Negotiable, Valuable, Estimable, Small and Testable.
Splitting stories. Large stories (epics) are split into smaller stories by workflow step, business rule, data variation, user role or happy path vs. exceptions.
Definition of ready and definition of done. Teams agree on what a story needs before it enters a sprint (definition of ready: clear acceptance criteria, dependencies identified, estimated) and what "done" means (built, tested, documented, accepted).
Backlog refinement. BAs work with the product owner and developers to clarify, split, estimate and order stories. Story points estimate relative effort.
Common story mistakes. Stories written as technical tasks ("Create a field"), missing the "so that," acceptance criteria that aren't testable, and stories too big for one sprint.
A complete story card with testable acceptance criteria.
Example stories.
| Story | Acceptance criteria (summary) |
|---|---|
| As a support agent, I want to see the customer's last five orders on the case so that I can resolve order questions without switching systems | Given a case with a contact, when I open it, then a related list shows the contact's five most recent orders with date, number and status |
| As a sales manager, I want opportunities over $100,000 to require my approval before Closed Won so that discounts are controlled | Given an opportunity over $100,000, when a rep sets Closed Won, then an approval request is sent to the manager and the stage is locked until approved |
| As a marketing ops user, I want duplicate leads blocked on creation so that our database stays clean | Given an existing lead with the same email, when a new lead with that email is created, then the user sees a duplicate warning and can't save |
Practice questions: User Stories
Question 1. Which is the best-written user story?
- A. Create a checkbox field on Account
- B. As a sales rep, I want to flag strategic accounts so that I can prioritize my outreach
- C. Make accounts better
- D. Accounts need fields
Answer: B. It has a role, capability and benefit.
Question 2. What's the purpose of acceptance criteria?
- A. Define conditions that must be met for the story to be accepted
- B. List the developers working on the story
- C. Describe the company history
- D. Replace testing
Answer: A. Acceptance criteria make stories testable.
Question 3. A story is too large to finish in one sprint. What should the team do?
- A. Split it into smaller stories that each deliver value
- B. Extend the sprint
- C. Skip acceptance criteria
- D. Remove the "so that" clause
Answer: A. Split epics into smaller, valuable stories.
Question 4. In INVEST, what does "T" stand for?
- A. Testable
- B. Technical
- C. Timeboxed
- D. Tracked
Answer: A. Stories must be testable.
Question 5. Which acceptance criterion is written in Given/When/Then format?
- A. Given an opportunity in Negotiation, when the amount exceeds $50,000, then manager approval is required
- B. The system should handle approvals
- C. Approvals are important
- D. Managers approve stuff
Answer: A. It specifies context, action and outcome.
Question 6. Which two items are commonly part of a definition of ready? (Choose two.)
- A. Clear acceptance criteria
- B. Dependencies identified
- C. Deployed to production
- D. User training completed
Answer: A and B. Ready means the team can start; done includes deployment and acceptance.
Development Support and User Acceptance (12%)
Supporting development. During the build, BAs clarify requirements, answer questions, review designs and demos, and keep stories and traceability up to date. They help the team understand business rules and edge cases, and they participate in sprint reviews.
User acceptance testing (UAT). UAT confirms that the solution meets business needs from the user's perspective, in a production-like environment (usually a full or partial copy sandbox).
- Plan: define scope, entry and exit criteria, environment, test data, roles and schedule.
- Prepare: write test scripts or scenarios based on acceptance criteria and business processes. Recruit testers who represent real users.
- Execute: testers run scenarios and record results and defects.
- Triage: classify defects by severity and priority, distinguish defects from new requirements (change requests), and retest fixes.
- Sign off: the business owner confirms exit criteria are met.
Testing types to recognize.
| Testing type | Who and what |
|---|---|
| Unit testing | Developers test individual components |
| System or integration testing | The team tests the whole solution and integrations |
| Regression testing | Confirms existing features still work after changes |
| UAT | Business users confirm the solution meets their needs |
| Performance testing | Checks speed and scale |
Go-live and post-launch. BAs support release planning, training materials, cutover tasks, hypercare and gathering feedback for future enhancements. Measure adoption and success KPIs after launch.
UAT confirms business fit before release.
Practice questions: Development Support and UAT
Question 1. Who should perform user acceptance testing?
- A. Business users who represent the people who'll use the system
- B. Only developers
- C. Only the scrum master
- D. External auditors
Answer: A. UAT is performed by representative business users.
Question 2. During UAT, a tester asks for a new report that wasn't in the requirements. How should the BA handle it?
- A. Log it as a change request or new backlog item, not a defect
- B. Mark it as a critical defect
- C. Fail the entire UAT
- D. Build it in production
Answer: A. New requests aren't defects; they go through prioritization.
Question 3. What should UAT test scripts be based on?
- A. Acceptance criteria and business processes
- B. Developers' preferences
- C. The org's fiscal year
- D. Random clicks
Answer: A. Scripts trace to requirements and acceptance criteria.
Question 4. Which environment is most appropriate for UAT with realistic data volumes?
- A. Full copy sandbox
- B. Developer sandbox
- C. Production
- D. A Trailhead Playground
Answer: A. Full copy sandboxes provide production-like data.
Question 5. After a release adds new fields, the team confirms existing case assignment still works. What type of testing is this?
- A. Regression testing
- B. UAT only
- C. Unit testing only
- D. Prototyping
Answer: A. Regression testing confirms existing functionality.
Deep dive: Salesforce features every BA should recognize
The exam isn't a configuration test, but many answers depend on knowing what Salesforce can do without custom code. When a requirement comes up, a strong BA can say whether it's a standard fit, a configuration gap or a true custom build.
| Business need | Standard or declarative Salesforce feature |
|---|---|
| Route new leads or cases to the right team | Assignment rules, queues, Omni-Channel |
| Require manager sign-off on large discounts | Approval processes or Flow approvals |
| Automate updates, emails and record creation | Flow (record-triggered, scheduled, screen) |
| Block bad data on save | Validation rules, required fields, duplicate rules |
| Guide users through stages | Path with guidance for success, sales processes |
| Show different fields to different teams | Record types, page layouts, dynamic forms |
| Control who sees which records | Organization-wide defaults, role hierarchy, sharing rules |
| Measure performance | Reports, dashboards, report subscriptions |
| Give customers or partners access | Experience Cloud sites |
| Add third-party functionality | AppExchange apps |
| Answer questions or take actions with AI | Agentforce agents, prompt templates |
Fit, configure or build. A requirement that maps directly to a row above is usually a fit. One that needs a combination (for example, a Flow plus a custom field) is a configuration gap. One that needs Apex, Lightning Web Components or an integration is a custom build, with higher cost, testing and maintenance. Exam answers favor the lowest-effort option that fully meets the requirement.
Deep dive: agile vs. waterfall for BAs
Salesforce projects use agile, waterfall or hybrids. The BA's techniques are the same, but timing and artifacts differ.
| Aspect | Waterfall | Agile (Scrum) |
|---|---|---|
| Requirements | Gathered and signed off up front in a requirements document | Evolve in a prioritized backlog, refined every sprint |
| Change | Formal change control after sign-off | Expected; product owner reprioritizes the backlog |
| BA artifacts | Business requirements document, functional spec | Epics, user stories, acceptance criteria |
| Testing | Phase after build | Continuous, with UAT per release |
| Stakeholder feedback | At milestones | Every sprint review |
Exam scenarios often signal the method with words like "sprint," "backlog" or "product owner" (agile) or "sign-off" and "phase" (waterfall). Pick answers that fit the method described.
Deep dive: writing requirements for AI and Agentforce features
AI features add new requirement categories that a BA should capture:
- Scope of the agent: which topics and actions it handles, and which it must hand off to a human.
- Data and grounding: which records, knowledge articles or Data 360 data the agent may use.
- Trust and guardrails: what the agent must never do, tone, and how to handle sensitive data.
- Success metrics: deflection rate, resolution rate, customer satisfaction, accuracy against test conversations.
- Testing: utterance-based test cases with expected responses, reviewed by business users before release.
User stories still work: "As a customer, I want to check my order status in chat so that I don't have to wait for an agent." Acceptance criteria describe the expected agent behavior for specific utterances. The Agentforce Specialist study guide covers the platform side.
Worked example: from request to release
The request. The service director at Cascade Insurance says, "Our agents are too slow. We need a new console."
Discovery. The BA interviews the director, observes six agents for half a day each and reviews case reports. Observation shows agents switching between Salesforce and a policy system 8 to 10 times per case and manually copying policy numbers. The real problem: lack of policy context on the case, not the console itself. The BA writes a problem statement and a KPI: reduce average handle time by 15% within three months.
Stakeholders. The director (high power, high interest: manage closely), agents (low power, high interest: keep informed and involve as testers), IT integration team (consulted), compliance (consulted on data display), the CIO (high power, low interest: keep satisfied). RACI: the director is accountable for scope decisions.
Process mapping. A current-state swim lane shows customer, agent, policy system and supervisor lanes, with the system switching and a rework loop when policy numbers are mistyped. The future state shows policy data displayed on the case, with escalation routed by Flow.
Requirements. Business: reduce handle time 15%. Functional: display policy summary on the case; auto-populate the policy number from the contact. Non-functional: the policy panel loads within two seconds; only licensed agents see coverage amounts. Transition: train 120 agents. MoSCoW marks the policy panel as Must, auto-escalation as Should and a new dashboard as Could.
User stories. "As a service agent, I want to see the customer's active policies on the case so that I can answer coverage questions without switching systems." Acceptance criteria: given a case linked to a contact with active policies, when the agent opens the case, then a panel lists policy number, type, status and renewal date within two seconds.
Development support and UAT. The BA answers developer questions about which policies count as active, reviews the sprint demo and updates traceability. UAT runs in a full copy sandbox with eight agents using scripts based on acceptance criteria. Two defects (wrong policy status mapping) are fixed and retested; one request for a new dashboard is logged as a backlog item. The director signs off. After go-live, the BA tracks handle time against the KPI.
One request, followed through every exam section.
Hands-on checklist
- Pick a real process you know (expense approval, lead follow-up, onboarding) and map the current state as a swim lane diagram.
- Map the future state using Salesforce features such as Flow, approval processes and assignment rules.
- Build a stakeholder power and interest grid and a RACI for a hypothetical project.
- Write five requirements of different types, then rewrite any vague ones to be testable.
- Prioritize ten requirements with MoSCoW.
- Write five user stories with Given/When/Then acceptance criteria, and split one epic into three stories.
- Build a simple traceability matrix linking requirements to stories and test cases.
- Write a UAT plan with entry and exit criteria and three test scripts.
- In a Developer Edition org, build one of your stories (for example, an approval process) and test it against the acceptance criteria.
Common exam traps
- "First" questions. The first step is almost always understanding the need or involving the right stakeholders, not configuring.
- Seniority isn't a tiebreaker. Facilitate based on business goals and escalate to the accountable person, rather than siding with the most senior voice.
- Defects vs. change requests. A new request during UAT is a backlog item, not a defect.
- Functional vs. non-functional. "What it does" vs. "how well it does it."
- Standard first. Prefer standard features and declarative tools if they meet the requirement.
- Stories are user-focused. "Create a field" is a task, not a story.
- Multiple-select questions. Read "Choose two" or "Choose three" carefully.
Flashcard terms
- Elicitation: drawing out requirements from stakeholders.
- Current state / future state: as-is vs. to-be.
- Gap analysis: what's missing between current and future states.
- Power/interest grid: stakeholder analysis tool.
- RACI: responsible, accountable, consulted, informed.
- Swim lane diagram: process map with lanes per role or system.
- BPMN / UPN: process notation standards.
- Functional / non-functional requirement: what vs. how well.
- Transition requirement: what's needed to move to the new state.
- MoSCoW: must, should, could, won't.
- Traceability matrix: links requirements to stories and tests.
- User story: As a, I want, so that.
- Acceptance criteria: Given, When, Then.
- INVEST: independent, negotiable, valuable, estimable, small, testable.
- Epic: a large story to be split.
- Definition of ready / done: entry and exit criteria for stories.
- UAT: business users confirm the solution meets needs.
- Regression testing: confirms existing features still work.
Mixed practice exam: 10 more questions
Question 1. A BA joins a project already in progress. What should they review first?
- A. Project goals, existing requirements and stakeholder list
- B. Apex test coverage
- C. The org's login history
- D. Dashboard colors
Answer: A. Understand goals, scope and stakeholders.
Question 2. A compliance officer must approve how customer data is displayed but isn't doing the work. In the RACI, they are:
- A. Consulted (or Accountable if they own the decision)
- B. Responsible
- C. Not included
- D. Informed only after go-live
Answer: A. Compliance typically gives input, and may be accountable for specific decisions.
Question 3. Which document is most useful for impact analysis when a requirement changes?
- A. Traceability matrix
- B. Org chart
- C. Login history
- D. Training calendar
Answer: A. Traceability shows which stories and tests are affected.
Question 4. A requirement says "The system shall be secure." What should the BA do?
- A. Work with stakeholders to define specific, testable security requirements
- B. Accept it as written
- C. Remove it
- D. Mark it Won't Have
Answer: A. Vague requirements must be made specific and testable.
Question 5. Which elicitation technique helps stakeholders who struggle to describe what they want?
- A. Prototyping
- B. Document analysis only
- C. A traceability matrix
- D. Regression testing
Answer: A. Prototypes make ideas tangible.
Question 6. A sprint review is primarily for:
- A. Demonstrating completed work to stakeholders and gathering feedback
- B. Writing code
- C. Assigning blame for defects
- D. Planning the next fiscal year
Answer: A. Sprint reviews demo work and collect feedback.
Question 7. Which two artifacts best describe a future-state process to developers? (Choose two.)
- A. Future-state swim lane diagram
- B. User stories with acceptance criteria
- C. The company's marketing brochure
- D. Last year's org chart
Answer: A and B. Process maps and stories guide the build.
Question 8. What's the main risk of skipping current-state analysis?
- A. Automating a broken process or missing hidden requirements
- B. Too much documentation
- C. Faster delivery
- D. Lower Salesforce licensing cost
Answer: A. You can't improve what you don't understand.
Question 9. Users keep entering opportunities without close dates. What's the BA's best first step?
- A. Understand why (missing training, unclear process or unknown dates) before proposing a validation rule
- B. Immediately make the field required
- C. Delete those opportunities
- D. Remove the field
Answer: A. Find the root cause before choosing a solution.
Question 10. UAT exit criteria are met. What's next?
- A. Business owner sign-off and release preparation
- B. Restart discovery
- C. Delete the sandbox immediately
- D. Skip training
Answer: A. Sign-off leads to release planning.
Quick-reference cheat sheet
| Topic | Remember |
|---|---|
| Format | 60 + 5 questions, 105 minutes, 72% to pass |
| Largest section | Collaboration with Stakeholders 23% |
| First step | Understand the need and stakeholders |
| Stakeholder tools | Power/interest grid, RACI, communication plan |
| Process maps | Current vs. future, swim lanes, levels |
| Requirements | Business, stakeholder, functional, non-functional, transition |
| Prioritization | MoSCoW, value vs. effort |
| Stories | As a, I want, so that; Given, When, Then; INVEST |
| UAT | Business users, full copy sandbox, defects vs. change requests |
| Design bias | Standard and declarative first |
Save this card for review week.
Frequently asked questions
Do I need the Administrator certification first? No. The prerequisite was removed on May 2, 2023. Platform knowledge still helps, and the Administrator study guide is a good companion.
Is the Business Analyst exam hard? It's scenario-based and wording matters. People with real project experience usually find it manageable; people without it should practice with realistic scenarios.
Is it worth it? It signals functional skills that employers value for BA, consultant and product owner roles, especially combined with Administrator.
How long should I study? Four to six weeks for most people with some Salesforce exposure.
Which notation should I learn? Understand swim lanes and basic BPMN symbols. The exam focuses on using process maps well rather than memorizing notation rules.
Related study guides
- Salesforce Administrator study guide.
- Salesforce Platform Foundations study guide for Salesforce basics.
- Salesforce Platform App Builder study guide for solution design.
- Data 360 Consultant study guide.
- All Salesforce certification study guides.
- The science of studying for Salesforce certifications for active recall, spaced repetition and an Anki workflow.
- Agentforce Sales Consultant (formerly Sales Cloud Consultant) study guide for applying discovery and requirements skills to a sales implementation.
Want to go deeper on automation? Many future-state processes you map will be built with Flow, the only supported declarative automation tool now that Workflow Rules and Process Builder are past end of support. My Salesforce Flows course walks through record-triggered, screen, scheduled and platform event flows with real-world challenges.
Hope this helps!
Best,
Nick