Explanation:

A cost-benefit analysis quantifies the financial return on an investment. "Cost savings" refers to a direct reduction in operational expenses.

Why Option B is Correct:
Reduced license count translates directly into a lower recurring software expense. If the Service Cloud implementation led to efficiencies that allowed the company to serve the same (or more) customers with fewer service reps, they could reduce their number of Salesforce licenses.

This is a clear, quantifiable hard cost saving. The finance department can easily calculate the exact dollar amount saved per year by multiplying the number of licenses removed by the cost per license.

It is one of the most straightforward and impactful metrics to demonstrate tangible financial return.

Why the other options are incorrect:
A. KPIs for CSAT: Customer Satisfaction (CSAT) is a quality and value metric, not a direct cost-saving metric. While higher satisfaction can lead to long-term benefits like customer retention and increased revenue, it does not directly reduce operational expenses in the short term. It reflects the "benefit" side of the analysis in terms of quality, not the "cost saving" side.

C. Reduced service rep backlog: This is an operational efficiency metric. A reduced backlog means the team is resolving cases faster and is more productive. However, this only translates into cost savings if it leads to a tangible reduction in expenses, such as:
- Reduced overtime pay (a cost saving).
- The ability to handle increased volume without hiring (cost avoidance).
- The ability to reduce staff or licenses (a direct cost saving, which is what Option B states directly).

On its own, a reduced backlog is a measure of productivity, not a direct financial saving.

Key Concepts & References:
Cost-Benefit Analysis (CBA): A process to calculate the financial benefits of a project against its costs. "Cost savings" are reductions in existing expenses.

Hard vs. Soft Savings:
- Hard Savings (Option B): Direct, quantifiable reductions in cost (e.g., lower software bills, reduced payroll).
- Soft Savings (Options A & C): Improvements in efficiency or quality that have financial value but are less directly quantifiable (e.g., higher productivity, better customer retention).

ROI Calculation: For a CBA, hard savings like reduced license counts are the most powerful and easily accepted figures.

In summary, while improved CSAT and reduced backlog are excellent measures of success, the one that directly and quantifiably reflects a reduction in operational cost is a reduced license count.

Explanation:

Here’s how this maps to the requirement:
“see which service reps are online, their current presence status, how long they've been logged in, and their capacity utilization for both primary and interruptible work.”

That is exactly what Omni Supervisor → Service Reps tab → All Agents subtab is designed for:
- Which reps are online – shows agents currently logged in to Omni.
- Current presence status – e.g., Available, Busy, Offline, custom statuses.
- How long they’ve been logged in / in a status – columns for duration in current status.
- Capacity utilization (primary & interruptible work) – shows current load vs. capacity, often broken down by work item types.

Why not the others?
B. Wallboard tab with actionable items
Wallboard is more about high-level KPIs and summary metrics (like volumes, handle times, SLAs).
It does not give you detailed per-agent presence and capacity view in the same way.

C. Assigned Work tab and Work Summary view
These focus on work items (what’s assigned, which queues, etc.), not primarily on agent presence, login time, and capacity utilization in one place.
You’d see workload, but not the full agent-centric, real-time view described.

✅ So the best fit for a real-time supervisor-style dashboard for agent online status, presence, login time, and capacity is:
A. The Service Reps tab and All Agents subtab.

Explanation:

The requirement specifies two key actions: archive the data and then access that archived data from an External Object.

Archiving: To manage 5 years of data efficiently, the historical Case records must be moved out of the main Salesforce database to a cost-effective external data store (like AWS S3, Azure, or an external database).

External Object Access: The key is to access this data using an External Object within Salesforce. An External Object allows the archived data, which physically resides outside of Salesforce, to appear and behave like a standard Salesforce object.

Salesforce Connect: Salesforce Connect is the technology that links (integrates) the Salesforce org to the external data source and exposes that external data as a native External Object. It uses protocols like OData or custom adapters to query the data in real-time, allowing CK users to view the archived cases on demand without having to store all five years of data in their expensive primary Salesforce storage.

This combination of external storage + Salesforce Connect + External Objects is the standard, best-practice pattern for archiving large volumes of historical data while maintaining user access.

Analysis of Incorrect Answers
A. Salesforce Big Object
Why it is incorrect: Big Objects are designed for storing massive amounts of data (billions of records) on the Salesforce platform, not externally. While they are often used for historical archiving to save on standard storage costs, the question specifically asks about accessing the data from an External Object. Big Objects do not use External Objects for access; they are queried directly (often with Async SOQL).

C. Salesforce Case History Object
Why it is incorrect: The Case History Object stores changes made to fields on the Case record (Field History Tracking). It is used for auditing and tracking, not for archiving entire Case records (5 years of data) or integrating with an External Object.

References
Salesforce Connect: The feature that allows the display and access of data stored outside of Salesforce (archival or operational data) via External Objects. (Source: Salesforce Integration/Platform documentation)

Archiving Pattern: The use of external storage combined with Salesforce Connect is the recommended architecture for data archiving where the historical data must remain visible to users.

Explanation:

This question tests the knowledge of the specific sharing mechanism designed for granting record access to external users in an Experience Cloud site based on a lookup relationship.

Requirement: Customers (external Experience Cloud users) should only see and edit Cases where they are the listed Contact.

Why Option B is Correct:
Sharing Sets are a feature built specifically for Experience Cloud (formerly Community Cloud).

They are designed to grant access to records for external users based on a relationship between the user and the record.

The standard configuration is to create a Sharing Set that grants access to Case records where the "Contact ID" field on the Case equals the "Contact ID" of the logged-in Experience Cloud user.

This automatically and securely ensures that a customer can only see the cases linked to their own contact record, regardless of who created the case (themselves or a support agent). This is the standard, out-of-the-box solution for this requirement.

Why the other options are incorrect:
A. A sharing rule to ensure record access is granted based on the Experience Cloud site user role hierarchy.
Sharing Rules are primarily used for sharing records among internal users based on public groups, roles, or territories. The role hierarchy for external Experience Cloud users is typically very flat and is not the standard or efficient mechanism for granting record access based on a contact lookup. Sharing Sets are the direct and simpler tool for this purpose.

C. An organization-wide default of Public Read/Write on the Case object.
This is extremely insecure and incorrect. Setting the Organization-Wide Default (OWD) for Cases to Public Read/Write would mean every single customer in the portal could see and edit every single case, which is a massive data breach. OWD sets the most restrictive level of access, which should be Private for Cases. Sharing Sets, Roles, and Rules then open up access from that baseline. Starting with Public Read/Write is a critical security failure.

Key Concepts & References:
- Sharing Sets: The primary tool for granting record access to Experience Cloud members based on a shared field value, most commonly the Contact lookup.
- Organization-Wide Defaults (OWD): The most restrictive baseline level of access for a record. For customer data in a portal, the OWD for Cases should typically be Private.
- Experience Cloud Security Model: Access is managed through a combination of OWD, Licenses, Profiles, Permission Sets, and Sharing Sets.
- Licenses and Sharing: External users have specific licenses (e.g., Customer Community Plus) that work in conjunction with Sharing Sets to provide secure, scalable access.

In summary, to grant a customer access to cases where they are the contact, the consultant must configure a Sharing Set, which is the native, secure, and scalable solution for this exact scenario.

Explanation:

Why C is correct
In Service Cloud, Support Processes control which Case Status values are available for a given process. They’re designed exactly for scenarios where different teams (or business units) use different case lifecycles.

You would:
- Create two Support Processes:
- Billing Support Process → Status values: New, Under Review, In Progress, Blocked, Closed
- Product Development Support Process → Status values: New, Under Review, In Progress, Closed

- Create two Case Record Types, one for each team, and assign:
- The Billing Support Process to the Billing record type.
- The Product Development Support Process to the Product Development record type.

- Assign the right record type to each team via profiles or permission sets so:
- Billing sees its full lifecycle (including Blocked).
- Product team never sees Blocked as an option.

This gives each team the correct lifecycle at the Status picklist level, cleanly and natively.

Why not the others?
A. Create a Path widget to visualize each team's lifecycle.
Path only visualizes stages; it does not control which Status values are available.
The underlying Status picklist would still show all values to all users unless controlled via Support Processes/record types.
So Path alone doesn’t enforce different lifecycles.

B. Use dynamic forms to hide unnecessary options for each team's lifecycle.
Dynamic Forms currently apply to some standard objects (like Account, Contact, etc.), but Cases use page layouts & Support Processes for Status configuration.
Even conceptually, dynamic visibility would hide fields or sections, not cleanly manage separate Status value sets per team.
This is more of a UI hack, not the correct data model solution.