Explanation:

When creating a new user in Salesforce, the "Working Hours" field is not part of the standard user creation process. Working Hours are typically defined within other Salesforce features such as Service Cloud (Service Resources and operating hours), Salesforce Scheduler (appointment availability), and Entitlement Management (business hours for support). These belong to organizational or feature-level configurations, not individual user defaults. The only settings directly applied to a user during creation are Time Zone, Language, and Locale.

Analysis of Other Options:
A. Time Zone: This CAN be selected. It is a mandatory field that determines how timestamps appear for the user.

B. Language: This CAN be selected. It controls the language of the Salesforce interface, labels, and help for the user.

D. Locale: This CAN be selected. Locale determines formatting for dates, numbers, addresses, and names. It is separate from the Language setting.

Reference:
This explanation is based on hands-on Salesforce experience. You can verify it by navigating to Setup > Users > New User, where Time Zone, Language, and Locale are available — but not Working Hours.

Explanation:

Why C is correct
The BA is responsible for defining enhancement features that must be configured in the next Salesforce CPQ phase. This requires documenting:

- What the system must do
- Expected behavior
- Required configurations
- Rules, conditions, calculations, validations
- Inputs/outputs

This level of detail belongs in a Functional Requirements Specification (FRS).
It describes how the system should behave to support the requested enhancements.

Why not A: Business analysis plan
A Business Analysis Plan outlines:
- BA activities
- Deliverables
- Methods of working
- Stakeholder engagement strategy

It does not define enhancement features.

Why not B: Scope statement specification
A Scope Statement defines:
- What is in scope vs. out of scope
- High-level boundaries

It does not provide the detailed descriptions needed for configuring enhancements in CPQ.

Summary
To define the next phase of CPQ enhancement features, the BA should prepare a Functional Requirements Specification → C.

Explanation:

The ability to use the Salesforce Authenticator mobile app to approve identity verification, multi-factor authentication (MFA), and unlock a locked user account is a core security feature available on the app regardless of the distribution platform.

The Salesforce Authenticator app is available for download on both major mobile operating systems:

- iOS (via the Apple App Store)
- Android (via the Google Play Store)

This functionality is dependent on the application's design and its connection to the user's Salesforce account, not the platform it was downloaded from or whether it was installed via the AppExchange (which is a marketplace for Salesforce extensions, not for native mobile applications).

❌ Incorrect Answers and Explanations

B. iOS (App Store)
This is incorrect because the same functionality is also available on the Android version of the app.

C. Only those that download the app from the App Exchange.
This is incorrect. The AppExchange is primarily for installing managed or unmanaged packages into a Salesforce org. Native mobile apps like Salesforce Authenticator are downloaded directly from the official mobile application stores (App Store/Google Play), and the functionality is universal.

D. Android (Google Play)
This is incorrect because the same functionality is also available on the iOS version of the app.

References
Salesforce Documentation: Salesforce Authenticator:

Key Concept: The Salesforce Authenticator mobile application (available on both iOS and Android) is designed for multi-factor authentication, including the ability for an end-user to quickly unlock their own account when locked due to failed login attempts.

Salesforce Trailhead Module: Multi-Factor Authentication (MFA) Basics:
Key Concept: Salesforce highly recommends and enforces MFA, with the Salesforce Authenticator app being a key verification method across supported mobile platforms.

Explanation:

In the given scenario, the core problem is that the requirements tracking spreadsheet is incomplete and out-of-sync—meaning multiple team members are likely editing it independently, leading to version conflicts and outdated information. A DevOps tool (such as Salesforce DevOps Center, Copado, Gearset, or Jira with Salesforce integration) replaces manual spreadsheets with a centralized, real-time collaboration platform that serves as the single source of truth (SSoT) for requirements, user stories, and changes.

Why Option C is correct:
- Real-time tracking: Changes made by the BA, developers, testers, or stakeholders are reflected instantly across the team—no more "which version is current?" confusion.
- Single source of truth: The DevOps tool maintains one authoritative record of requirements, linked to work items, user stories, and deployment pipelines.
This directly solves the out-of-sync spreadsheet issue by eliminating parallel edits and version mismatches.

Salesforce Guidance:
Salesforce DevOps Center (released generally in 2023) is designed to "provide a single source of truth for work across the entire team" — Source: Salesforce DevOps Center Trailhead Module

Why the Other Options Are Incorrect

Option A: Tracks changes on a daily basis and provides a history of changes
This option falls short because it implies a delayed, batched tracking cadence ("daily basis") rather than the immediate, continuous synchronization required to resolve the core issue of an out-of-sync spreadsheet. In a fast-moving Slack transition project, waiting until the end of the day to capture changes risks the same version conflicts and incomplete data the BA is already experiencing. While DevOps tools do maintain a full audit trail and history of changes (a valuable secondary benefit), this is not the primary advantage in this context. The real problem is real-time alignment across the team, not merely having a historical log after the fact. Thus, Option A addresses a symptom (history) but not the root cause (lack of live synchronization).

Option B: Tracks changes for the testing team and provides access to user stories
This choice is too narrowly scoped and misaligns with the BA’s stated pain point. The frustration stems from requirements tracking being incomplete or out-of-sync for the entire project team, not just the testing group. Focusing benefits solely on testers ignores the broader collaboration needs of developers, architects, product owners, and the BA themselves. While providing user story access is a standard feature of DevOps tools, it is a means, not the end—the end goal is a unified, authoritative view of requirements. By framing the benefit as tester-centric, Option B fails to recognize the cross-functional, enterprise-wide synchronization that a DevOps tool delivers as its defining value, making it an incomplete and misleading answer.

Final Tip for Exam (BA-201):
When you see "spreadsheet" + "out of sync", think DevOps tool = single source of truth in real time. This is a common pattern in Salesforce BA exam scenarios.

Explanation:

Why Answer C Is Correct
The very first discovery meeting for a Service Cloud rollout at Northern Trail Outfitters is all about one thing: understanding what’s broken today. The new business analyst’s job is to map the internal support team’s world—how they handle tickets, where they get stuck, and why users hate (or avoid) the current system. That starts with limitations of the current support process.

Imagine walking into the meeting. The BA opens with:

- “Walk me through a typical support request—from the moment an employee emails to when it’s resolved.”
- “Where do you waste the most time?”
- “What do you wish worked better?”

The team spills:

- “We use email and spreadsheets—nothing links.”
- “No visibility into who’s working on what.”
- “Customers wait 3 days for a status update.”

Those pain points become the north star for Service Cloud. The BA turns each limitation into a requirement:

- Limitation: No central case tracking → Requirement: All support requests in one Case object.
- Limitation: Manual status emails → Requirement: Auto-notifications via Email-to-Case.
- Limitation: Duplicate work → Requirement: Knowledge articles for common issues.

Gathering limitations first gives the BA:

- Clear scope (what Service Cloud must fix).
- Stakeholder buy-in (they see their problems acknowledged).
- Prioritization (fix the biggest pains first).

This is discovery 101—start with the problem, not logistics or HR cycles.

Why Answer A Is Incorrect

Contact information for key stakeholders is logistics, not discovery. You’ll get emails and titles eventually (maybe in a RACI or stakeholder map), but day-one focus is process and pain, not phone numbers. Collecting contacts without context wastes time.

Why Answer B Is Incorrect

Employee review cycle is HR data—maybe useful for change management or training plans six months from now. It has zero impact on Service Cloud design. The BA isn’t building performance reviews; they’re building case management.

References
Trailhead module: Discovery for Service Cloud – “Identify Current Process Limitations” unit.
Salesforce Help: Run Effective Discovery Workshops.