Explanation:

To get feedback from a small group of end users before rolling out the Opportunity feature, the best approach is to show, not tell.

A live demo (or recorded walkthrough) allows users to:
- See how the feature works in the real UI
- Ask questions in real time
- Try it themselves immediately after the demo
- Provide concrete feedback based on actual behavior and screens

This aligns with Option B.

Why not A or C?
A. Share user stories about the feature
User stories are useful for requirements and development, but end users usually want to know "What do I click and how does this help me?" rather than reading "As a user, I want…" narratives.

C. Create a feature manual
Manuals can be useful later for training or reference, but they take longer to produce and users may not read them thoroughly. They are not the most effective way to gather practical, experience-based feedback quickly.

Correct Approach:
B. Demo the new feature.

Explanation:

To evaluate the risk level of user stories in a Salesforce Field Service implementation, the Business Analyst should assess how each story might impact:

Technical: Does the story require complex integrations, custom development, or changes to core architecture?
Operational: Will it significantly alter business workflows, user responsibilities, or service delivery processes?
Regulatory: Does it involve compliance with industry standards, data privacy laws, or audit requirements?

Assessing these three dimensions helps identify high-risk stories that may require additional testing, stakeholder alignment, or mitigation planning.

Why not the others?
A. Scope, resource, and documentation impact
These are project management considerations, not direct indicators of user story risk.

B. Team, budget, and timeline impact
These relate to project constraints, not the inherent risk of implementing the user story or compliance implications.

Reference:
Trailhead: User Stories
Salesforce Business Analyst Certification Guide

Explanation:

Among the issues listed, technical debt poses the greatest long-term risk to the success of a Sales Cloud implementation. Technical debt refers to outdated, inefficient, or poorly implemented configurations, custom code, or architectural decisions that accumulate over time.

If admins lack time or expertise to address it, technical debt can lead to:
- System instability
- Poor performance
- Increased cost of future enhancements
- Security vulnerabilities
- Difficulty scaling or integrating with other systems

This directly affects the foundation of the org, making it harder to deliver value and maintain agility.

Why not the others?
A. No knowledge transfer from previous partner
While inconvenient, this can be mitigated by reverse-engineering solutions, reviewing documentation, or conducting stakeholder interviews. It is a recoverable gap, not a systemic risk.

B. Support team needs training
Training is part of standard change management. It is important but not as structurally critical as unresolved technical debt.

Reference:
Trailhead: Application Lifecycle and Technical Debt
Salesforce BA Certification Guide

Explanation:

The Business Analyst's (BA) goal is to understand the customer's pain points regarding the existing functionality being difficult to use.

A Journey Map (or Customer Journey Map) is the ideal document for this. A Journey Map focuses specifically on the end-to-end experience of the customer or end-user as they interact with the service or application. It explicitly captures:

Actions: The steps the customer takes.
Touchpoints: The systems and people they interact with.
Emotions/Morale: Crucially, it tracks the user's feelings (their pain points) at each step of the process.

By reviewing the existing Journey Map, the BA can visually pinpoint the exact steps where the customer's emotions dip (indicating "pain points" and "difficult to use" areas), providing the necessary context and justification before writing requirements for the new Service Cloud feature.

❌ Incorrect Answers

B. Process map: A Process Map (or flowchart) documents the steps and decisions of the internal business process (the how work gets done). While it shows inefficiency, it focuses on the internal system and worker flow, not the external customer's subjective experience, feelings, and frustrations (the pain points).

C. Capability map: A Capability Map models what the business does (e.g., "Handle Customer Service Inquiries") regardless of how it's done or what tool is used. It is a high-level strategic tool for assessing functionality gaps and overlaps, not a document for detailing user-specific, emotional pain points related to usability.

References

User Experience (UX) Design Methodology: Journey Maps are the standard UX artifact for detailing and communicating the user's experience and pain points to stakeholders and development teams.
Salesforce Certified Business Analyst Exam Guide: The exam covers defining and documenting requirements, which includes understanding the User Experience (UX). The BA's role often involves using UX artifacts, such as Journey Maps, to ensure new solutions directly address user frustration and friction.

Explanation:

Data governance ensures data is secure, accurate, and used appropriately. When auditing Field-level Security (FLS) on the Account object, the business analyst focuses on who can see or edit which fields. End users, as daily consumers of this data, are key stakeholders because they understand real-world usage patterns, pain points, and risks—information critical to validating and refining access controls.

Why C (They provide valuable feedback on how they use data) is the Correct Choice
End users participate in data governance by sharing insights during interviews, workshops, or surveys: how they access Account fields, why they need certain visibility, workarounds due to restrictive FLS, or risks from overexposure. This feedback ensures FLS aligns with business needs, supports compliance (e.g., GDPR, CCPA), and prevents both data breaches and productivity loss. For example, a sales rep might reveal they bypass FLS by exporting data—exposing a governance gap the BA can address.

Why A (They export their data back it up locally) is Not Correct
Exporting data for local backup is a user action, not participation in governance. In fact, it often violates policy and highlights a failure in governance controls. The BA would flag this as a risk, not a stakeholder contribution.

Why B (They implement their data entry workarounds in the system) is Not Correct
Workarounds (e.g., using free-text fields to store sensitive data) indicate poor governance, not participation in it. These shadow processes undermine FLS and data quality. The BA documents them to correct access, not to endorse them as governance input.

Reference
Salesforce Trailhead: Data Governance Basics – “Engage end users to understand data usage and access needs during security audits.”
Salesforce Help: Field-Level Security – Recommends gathering user input to ensure FLS supports business processes without compromising security.