Salesforce Certified Business Analyst — Practice Exam Set 1

Question 1

A Salesforce Business Analyst is beginning a new engagement. Which discovery activity should come first?

Accepted Answer

Discovery begins with understanding the WHY — the business goals, pain points, and current-state processes — through stakeholder interviews and observation. Starting with a demo or prototype introduces solution bias before needs are fully understood. Technical architecture review follows initial discovery to inform solution design.

Question 2

A Business Analyst needs to document the current state of a client's sales process. Which two discovery techniques provide the most accurate picture of how work actually gets done (versus how it's supposed to get done)? (Choose 2)

Accepted Answer

Direct observation (shadowing) and process walkthroughs with practitioners reveal the real-world process, including workarounds, unofficial steps, and inefficiencies that don't appear in documented procedures. Official documentation often reflects the intended process, not the actual one. Revenue targets are business metrics, not process inputs.

Question 3

During discovery, a Business Analyst identifies a stakeholder who manages the Salesforce org technically but rarely interacts with end users. How should this stakeholder's input be weighted?

Accepted Answer

Every stakeholder has a domain of expertise that should inform the appropriate part of the solution. The Salesforce admin/technical stakeholder provides valuable input on technical constraints, integration limitations, and feasibility. End user experience requirements must be gathered from those who perform the process daily. A skilled BA triangulates input from multiple stakeholder types without letting one perspective dominate out of its appropriate domain.

Question 4

A Business Analyst facilitating a discovery workshop notices that the VP of Sales and the Sales Operations Manager have conflicting views on how the pipeline should be managed. What should the BA do?

Accepted Answer

Conflicting stakeholder requirements are a normal discovery challenge. The BA's role is to surface, document, and facilitate resolution — not to unilaterally decide or design around the conflict. Escalating to the project sponsor ensures appropriate decision authority is involved. Trying to accommodate two conflicting approaches leads to a confused, unmaintainable solution. Deferring decisions creates scope risk for later phases.

Question 5

A RACI matrix is used in project management to define roles and responsibilities. What does the 'A' in RACI stand for?

Accepted Answer

RACI stands for Responsible (does the work), Accountable (owns the outcome and delegates), Consulted (subject matter experts who provide input), and Informed (kept up to date on progress). There can be multiple Responsible parties but only one Accountable person per activity. The BA uses RACI to clarify decision authority and prevent responsibility gaps in a Salesforce project.

Question 6

A Business Analyst is preparing for a requirements workshop with 15 participants from 4 departments. Which workshop facilitation technique prevents the workshop from being dominated by one or two vocal individuals?

Accepted Answer

Facilitation techniques like round-robin input (everyone shares in turn), dot voting (anonymous prioritization), and breakout groups prevent groupthink and vocal-minority dominance. These techniques surface diverse perspectives and build group consensus. Limiting attendance or deferring to seniority suppresses valuable operational insights from practitioners.

Question 7

A Business Analyst is managing stakeholder communication for a Salesforce implementation. Which two communication principles improve stakeholder engagement? (Choose 2)

Accepted Answer

Effective stakeholder communication requires tailoring content to the audience — executives need high-level summaries focused on business impact, while technical teams need detailed specifications. A regular communication cadence (status updates, milestone reviews) keeps stakeholders informed proactively, builds trust, and prevents surprises. One-size-fits-all documentation overwhelms some audiences. Communicating only during problems causes stakeholder anxiety and erodes confidence.

Question 8

A Business Analyst receives conflicting feedback from a business stakeholder ('Add the customer's revenue to the Account view') and a technical constraint from the IT team ('The revenue field is in the ERP and integration will take 3 months'). How should the BA address this?

Accepted Answer

The BA's role is to bridge business needs and technical constraints, not to decide unilaterally. Facilitating a three-way discussion (BA, stakeholder, IT) surfaces the available options (real-time integration via Salesforce Connect, nightly ETL, phase 2 deferral) with their respective timelines and costs. This allows the stakeholder to make an informed priority decision. A manual text field introduces data quality risk. Removing the requirement without stakeholder agreement creates scope conflict.

Question 9

Which stakeholder management strategy is appropriate for a stakeholder who has HIGH influence on the project but LOW interest in its day-to-day activities?

Accepted Answer

The stakeholder power/interest grid classifies stakeholders by influence and interest. High influence / low interest stakeholders should be 'kept satisfied' — they need periodic high-level updates on project health and milestone progress, and their input should be sought on key decisions that require their authority. Engaging them in detailed daily activities wastes their time and can cause disengagement. Ignoring them risks losing executive support when needed.

Question 10

A Business Analyst is running a sprint review demo for a Salesforce implementation. Which two practices make the demo most effective for gathering feedback? (Choose 2)

Accepted Answer

Effective sprint demos use realistic business scenarios with representative data so stakeholders can evaluate whether the solution fits their actual workflow. End user participation generates the most actionable feedback because they know what will and won't work in practice. Technical architecture presentations are not appropriate for sprint demos. Showing only polished work defeats the purpose of iterative reviews — partially-built features can still generate valuable directional feedback.

Question 11

A Business Analyst creates a process diagram that shows the flow of a sales process from Lead to Closed Won, including decision points, actors, and handoffs. What type of diagram is this?

Accepted Answer

A swim lane diagram (or BPMN — Business Process Model and Notation) maps the sequence of activities in a process, including decision gateways (yes/no branches), actors (swim lanes representing each role or department), and handoffs between parties. This is the standard tool for process mapping in Salesforce BA work. ERDs model data relationships; DFDs model data movement; Gantt Charts model project timelines.

Question 12

A Business Analyst completes a current-state process map and identifies several manual, repetitive steps that are candidates for automation in Salesforce. What document captures the recommended future state?

Accepted Answer

After documenting the current state (AS-IS process), the BA creates a Future State (TO-BE) process map that illustrates how the process will work after Salesforce implementation, including automated steps, eliminated steps, new roles/responsibilities, and improved handoffs. The gap between current state and future state defines the project scope. Future state maps are reviewed with stakeholders for validation before requirements are finalized.

Question 13

A Business Analyst is mapping a complex approval process for sales discounts. Which two elements must be captured in the process map? (Choose 2)

Accepted Answer

Business process maps capture business logic (decision gateways with conditions) and human actors (roles/departments responsible for each step). The discount approval map should show the branching conditions (thresholds that route to different approvers) and the role responsible for each approval level. Internal Salesforce object IDs and SOQL queries are technical implementation details, not business process map elements.

Question 14

A Business Analyst discovers during process mapping that the finance and sales teams have different definitions of 'Closed Won' — finance recognizes revenue when the contract is signed, while sales records it when the customer verbally commits. This is an example of:

Accepted Answer

Conflicting definitions of core business concepts (like 'Closed Won') are definitional ambiguity issues that represent fundamental business rule conflicts. If not resolved before design, the Salesforce solution will perpetuate the confusion. The BA must facilitate a business-led decision on the canonical definition of 'Closed Won' across all departments, which then drives the data model, field definitions, and automation. This is a discovery/requirements issue, not a technical one.

Question 15

What is the difference between a functional requirement and a non-functional requirement?

Accepted Answer

Functional requirements define system behaviors and features (e.g., 'The system shall automatically assign a lead to the nearest sales rep based on zip code'). Non-functional requirements (NFRs) define quality attributes (e.g., 'The system shall load the lead assignment in under 2 seconds' or 'The system shall be available 99.9% of the time'). NFRs are not optional — they constrain the architecture and design just as much as functional requirements.

Question 16

A stakeholder says: 'The system should make the sales process easier.' As a Business Analyst, how should you handle this requirement?

Accepted Answer

Vague, unmeasurable statements ('easier', 'better', 'faster') are opportunities for the BA to probe deeper with 5 Whys and clarifying questions to surface concrete, testable requirements. 'What steps currently take too long?' or 'What would success look like?' converts ambiguous business desires into specific, measurable requirements. Accepting vague requirements leads to scope disputes at UAT. Unilaterally assuming meaning introduces scope creep risk.

Question 17

A Business Analyst is reviewing a requirements document before sign-off. Which two characteristics define a well-written requirement? (Choose 2)

Accepted Answer

Well-written requirements are testable (you can write a test case to verify they are met) and unambiguous (every reader interprets them the same way). Requirements should be solution-neutral — they describe WHAT must happen, not HOW (the Salesforce feature choice belongs in the design). Comprehensive edge-case coverage can be achieved through multiple focused requirements rather than one compound statement.

Question 18

A business stakeholder requests mid-project: 'Can we also add automatic follow-up emails to prospects 30 days after the quote is sent? It won't take long.' The Business Analyst should:

Accepted Answer

Scope change — even 'small' additions — must be managed through a formal change control process. The BA documents the request, assesses the impact (design, build, test, and timeline effort), and presents the trade-off to the appropriate decision-maker (project sponsor or steering committee). 'Small' changes often have hidden complexity (e.g., email template design, opt-out compliance, Marketing Cloud integration). Unilateral implementation or backlog additions without impact assessment undermine project governance.

Question 19

What is the standard format for writing a user story in an Agile Salesforce project?

Accepted Answer

The standard user story format is: 'As a [role/persona], I want [goal/feature], so that [business value/reason].' This format keeps the focus on the user's perspective and the business benefit, not the technical implementation. Option C is the Given/When/Then format used for acceptance criteria, not the user story itself. Option D is a traditional requirement statement (shall statement), not a user story format.

Question 20

A user story is considered 'ready' for development when it meets the INVEST criteria. What does the 'T' in INVEST stand for?

Accepted Answer

INVEST is a quality checklist for user stories: Independent (not dependent on other stories), Negotiable (details can be discussed), Valuable (delivers user/business value), Estimable (the team can size it), Small (fits within a sprint), and Testable (acceptance criteria exist to verify completion). Testable is critical because without testable acceptance criteria, the team cannot objectively confirm the story is 'done.'

Question 21

A Business Analyst is writing acceptance criteria for a user story: 'As a sales rep, I want the system to automatically assign a new Lead to the correct sales rep based on state, so that leads are followed up immediately.' Which two acceptance criteria are appropriate? (Choose 2)

Accepted Answer

Acceptance criteria should be written in Given/When/Then format and describe observable, testable behaviors — not implementation details. Option A describes the expected outcome for a successful match. Option C describes the fallback behavior when no match exists — an important edge case. Option B specifies the technical implementation (Flow vs Apex), which belongs in the design, not acceptance criteria. Option D is about data model correctness, not the assignment story.

Question 22

What is the primary purpose of User Acceptance Testing (UAT) in a Salesforce implementation?

Accepted Answer

UAT is conducted by business end users to validate that the Salesforce solution meets the agreed business requirements and works correctly in real-world business scenarios. UAT confirms 'we built the right thing' — from the user's perspective. Unit testing covers code quality and Apex coverage. System testing covers technical bug finding. Sprint demos are development team showcases. UAT is the final gate before production go-live.

Question 23

Who is responsible for writing UAT test scripts for a Salesforce implementation?

Accepted Answer

UAT test scripts are business-driven documents that describe business scenarios and expected outcomes from a user perspective. The Business Analyst is best positioned to write them because they understand both the business requirements and the Salesforce solution. However, effective UAT test scripts are written collaboratively with business stakeholders and end users who can validate the scenarios are realistic and comprehensive. Developers writing their own test scripts creates a conflict of interest in catching their own omissions.

Question 24

A Business Analyst is managing UAT for a Salesforce Sales Cloud go-live. Which two practices improve UAT effectiveness? (Choose 2)

Accepted Answer

Realistic test data allows UAT testers to evaluate the solution against scenarios they recognize from their work, uncovering edge cases that generic test data misses. A structured defect log (with severity, reproduction steps, and expected vs. actual behavior) enables efficient triage and prioritization of issues before go-live. UAT must never be done in Production — it risks corrupting live data and blocking real business processes. Limiting UAT to one session pressures testers and results in incomplete testing.

Question 25

During UAT, a stakeholder raises a new enhancement request that was not part of the original scope. What is the Business Analyst's recommended course of action?

Accepted Answer

New enhancements discovered during UAT should be logged in the product backlog for a future phase rather than added to the current go-live scope. Adding scope during UAT extends timelines, may require re-testing of dependent features, and delays go-live. The BA documents the enhancement with enough detail to estimate and prioritize it in the next iteration. Dismissing it entirely or halting UAT are both overreactions. UAT defect logs are for bugs, not new features.

BA-201 — Salesforce Certified Business Analyst