Explanation:

Why A is correct
Field-level security (FLS) controls whether a user can see a field anywhere in Salesforce, including in reports. To hide a sensitive field from most users on a profile but allow a subset to report on it, keep the field not visible for the Sales profile and grant Read on that field via a permission set to just the Institutional Team.

Why the other options are wrong
B. You can’t “assign” a report type to users to bypass FLS. Custom report types define which objects/fields could be reported on, but users still only see fields allowed by FLS. A permission set cannot grant “report type access” in the way described.
C. Marking the field Read Only on the Sales profile still makes it visible, which contradicts “should be unable to access this field.” And there’s no separate “re-enable reporting” permission per field—reports respect FLS.
D. Sharing a report does not override FLS; users who don’t have visibility to a field won’t see its data in a shared report.

References
Salesforce Help: What Determines Field Access? (“Field-level security controls the visibility of fields … including … reports.”).
Salesforce Help: Set Field-Level Security for a Field on All Permission Sets (grant field Read/Edit via permission sets).

Explanation:

Cloud Kicks needs to make inventory data from a legacy application available for viewing and reporting in Salesforce without duplicating or manually managing the data. The solution should integrate the external data seamlessly into Salesforce. Here’s why creating an external object is the best approach and why the other options are less suitable:

A. Create an external object that maps to the inventory application:
External objects in Salesforce allow integration with external data sources (like the legacy inventory application) using Salesforce Connect. This enables real-time access to the external data, which can be viewed, queried, and included in reports within Salesforce as if it were native data. External objects are ideal for this scenario because they avoid data duplication, support reporting, and maintain data in the legacy system while making it accessible in Salesforce.

How it works:
Set up Salesforce Connect with an OData or custom adapter to connect to the legacy application’s API.
Define an external object in Salesforce that maps to the inventory data tables/fields in the legacy system.
Create external object relationships or custom report types to enable viewing and reporting in Salesforce.
Why it’s best:
This provides a scalable, real-time integration without manual data imports, aligning with the goal of viewing and reporting on inventory data.

Why not B (Import the data into a custom object when needed; delete after it is used)?
Importing data into a custom object requires manual or scheduled uploads (e.g., via Data Loader), which is inefficient and prone to errors. Deleting the data after use prevents historical reporting and creates a maintenance burden. This approach also risks data inconsistencies between Salesforce and the legacy system, unlike real-time access via external objects.

Why not C (Build a Lightning component and use SFDX to connect to the inventory app)?
While a Lightning component could display external data by calling the legacy application’s API, building a custom component requires significant development effort. Salesforce Developer Experience (SFDX) is a tool for source-driven development, not a direct integration method. This approach is overkill compared to external objects, which provide native integration and reporting capabilities without custom coding.

Why not D (Upload an Excel spreadsheet with the data into the Files tab)?
Uploading an Excel spreadsheet to the Files tab allows storage but does not integrate the data into Salesforce for viewing or reporting. Files cannot be queried or included in Salesforce reports, making this unsuitable for the requirement.

Additional Notes
Prerequisites: Ensure the legacy application has an API (preferably OData-compatible) or supports a custom adapter for Salesforce Connect. Salesforce Connect requires a separate license.
Reporting: To enable reporting, create a custom report type including the external object or relate it to other Salesforce objects (e.g., Accounts) if needed.
Security: Configure external object access via profiles or permission sets to ensure only authorized users can view the inventory data.

References
Salesforce Help: Salesforce Connect (Trailhead module: “Salesforce Connect” in the Admin Advanced Trailmap for external object setup).
Salesforce Help: External Objects (covers mapping external data for viewing and reporting).

Explanation:

The core problem is the time it takes to route the case to the correct support agent "by area of expertise according to product information" after submission.

Omni-Channel is the feature designed specifically to route work (like Cases) to the most qualified, available agent based on criteria such as skills, product expertise, and capacity.

The administrator would configure Omni-Channel by:

Defining Service Channels (e.g., Cases).
Creating Routing Configurations to define how cases are prioritized and routed (e.g., based on the Product field on the case).
Assigning agents Skills (e.g., "Sneaker Product Expert," "Boots Product Expert") and linking those skills to the Routing Configuration.
The system then automatically pushes the new case to the agent with the required skills and current capacity, dramatically reducing the time the case spends waiting for manual assignment.

This directly addresses the customer frustration regarding the time delay and the need for skill-based routing.

Why the Other Options are Incorrect

B. Escalation Rules:
These rules are used to move a case to a higher-level support tier or manager if it hasn't been solved within a specific time period (Service Level Agreement violation). They address time-to-resolution, but not the initial, correct-agent-assignment problem.
C. Macros:
Macros are productivity tools that let agents perform common repetitive tasks with a single click (e.g., sending an email, updating case fields). They improve agent efficiency after the case is assigned, but don't handle the assignment/routing process itself.
D. Knowledge Component:
The Knowledge component allows agents (or customers) to search for and attach relevant articles. This is excellent for case deflection or first-call resolution, but it is not a tool for routing a case to a specific agent.

Explanation:

Why C is correct?
With Salesforce Shield, you can use Enhanced Transaction Security (part of Shield Event Monitoring) to monitor and block risky data-exfiltration behaviors in real time—like report exports over a row threshold, exports of specific reports, or exports outside trusted networks. You can write ReportEvent policies that block downloads or end the session when conditions match, which directly addresses “prevent users from exporting more data than they need,” including reports that might contain bank accounts/PII.
Examples from Salesforce docs:
“For maximum coverage, write a policy that notifies you and blocks access to reports that process more than a certain number of rows. Block downloads for specific users or reports.”

Why the others are not

A. Salesforce Platform Encryption – Encrypts data at rest and (with the right options) in search indexes/files, but it doesn’t stop authorized users from seeing or exporting readable values. You still control visibility with FLS and permissions; encryption alone doesn’t limit export volume or block exports.
B. Export Data Settings – There’s no single “Export Data Settings” feature that lets you conditionally limit or block exports by row count or content. Export ability is mostly governed by user permissions (e.g., Export Reports, Weekly Data Export)—not a dynamic control on volume/PII.
D. Muted Permission Sets – Muting adjusts permissions inside a permission set group; it doesn’t provide event-based controls to block report/file exports. It won’t selectively limit how much data someone exports once they have access.

References:

ReportEvent policies (Transaction Security): block exports over N rows; block downloads for specific users/reports.
Transaction Security overview: intercept real-time events and apply actions (alert, block, end session).
Condition Builder / Rows Processed for Report Event monitoring.
Shield Platform Encryption overview (for context on why encryption ≠ export limiting).

Practical tip
In addition to Shield policies, ensure only necessary users have Export Reports / Data Export permissions and lock down sensitive fields via FLS—layering controls yields the best outcome.

Explanation:

Why it’s correct:
The Fields component in Lightning App Builder lets you place specific individual fields from a record anywhere on the Lightning page. This satisfies “only see certain fields” without exposing the rest of the page-layout fields.

Why the others are incorrect:
A. Record Detail Component – Renders the entire page layout (or a large section of it). You can’t easily restrict it to just a few fields unless you create and assign a separate page layout, which affects other contexts.
C. Highlights Panel Component – Shows fields from the Compact Layout and standard record actions. It’s limited to that top summary area and not intended for arbitrary subsets of fields throughout the page.
D. Path Component – Visualizes progress through a picklist path (e.g., Stage) and optional Guidance for Success. It doesn’t control field visibility for arbitrary fields.

References:
“Lightning App Builder – Standard Components (Fields, Record Detail, Highlights Panel, Path)” in Salesforce Help & Training / Trailhead documentation.
“Compact Layouts and the Highlights Panel” in Salesforce Help (for what appears in Highlights Panel).

Explanation:

Dynamic Actions (also known as Productivity Actions in Lightning) allow administrators to define visibility rules for Quick Actions, buttons, and other related lists on record pages. By using conditional visibility criteria—such as user profile, record type, or field values—you can ensure that only relevant actions (e.g., "Escalate Order" for Customer Service or "Convert to Quote" for Sales) appear for specific users. This keeps the page layout clean and user-friendly without requiring separate layouts or record types, directly addressing the frustration with irrelevant actions while maintaining a single shared page layout.

Why B is incorrect:
Creating separate record types would enable different page layouts for each user group, but this is overkill for the issue of action visibility. Record types are better suited for fundamentally different data structures or processes (e.g., "Service Order" vs. "Sales Order"), and they don't inherently control action visibility without additional setup.

Why C is incorrect:
Permission sets control access to objects, fields, and records (e.g., CRUD permissions), but they do not influence the UI display of actions on a page layout. Users would still see irrelevant actions even if they lack permission to use them, leading to the same frustration.

Why D is incorrect:
Creating separate Lightning record pages assigned to profiles would allow fully customized layouts (including actions), but this approach duplicates effort and maintenance for a single object. It's more appropriate for entirely different page experiences, not just conditional action visibility.

References
Salesforce Help: Dynamic Actions for Lightning Experience (explains conditional visibility for actions based on profiles and other criteria).
Trailhead: Optimize User Experience with Dynamic Forms and Actions module, which covers tailoring actions to user roles like Sales and Service.

Explanation:

This recommendation provides a two-part solution that addresses both the data quality/enforcement and the user experience/guidance issues:
Create a Validation Rule: This is the enforcement mechanism. A validation rule can be written to fire when the Opportunity Stage is changed to 'Qualified' (or a specific stage API Name) and check if the Use Case field is blank. If it's blank, the rule prevents the save, forcing the user to input the required data. This ensures the data quality requirement (100% completion) is met.
Add the Use Case field to the Stage Guidance in Path: This is the guidance mechanism. The Path component on the Lightning record page is designed to highlight key fields and provide success guidance for each stage. By adding the Use Case field to the guidance for the 'Qualified' stage, the user is visually prompted and reminded to fill out the field before they attempt to move the stage, reducing frustration from the validation rule.

Why the Other Options are Incorrect

A. Write a record-triggered flow that populates the Use Case field when an opportunity is closed:
This is incorrect for two main reasons:
The requirement is to input the data before moving to the 'Qualified' stage, not when the opportunity is closed.
A flow that populates the field would be filling it with generic data (or nothing at all), which goes against the requirement for the sales user to input a use case (varying text strings).
C. Make the Use Case field required on the master Opportunity layout:
This would make the field required every time an opportunity is created or saved, regardless of the stage. The requirement is to enforce the field only when moving to the Qualified stage, so making it universally required is overly restrictive and incorrect. Validation rules are the proper tool for conditional field requirements based on stage.
D. Use a quick action with the Use Case field in the layout, and add it as a Lightning component:
A Quick Action is used to create or update a record from a different place or with a simplified layout. While you could set up a Quick Action to update the field, it does not enforce the requirement. Users could still change the stage without using the action, and the data would remain incomplete, which is the current problem.

Explanation:

When you add a dashboard filter, such as Account Owner, Salesforce tries to apply that filter to all dashboard components. However, for the filter to work correctly, each component’s source report must include a field that matches the filter criteria — this is called the equivalent field.
In this case:
The dashboard filter is based on Account Owner.
The Opportunity reports must include the Account Owner field (not just Opportunity Owner).
If the Opportunity report doesn’t include Account Owner, the filter won’t apply properly, and records may be excluded.
Solution:
Modify the Opportunity reports used in the dashboard components to include the Account Owner field as the equivalent field. This ensures the filter works across all components.

❌ Why the other options are incorrect:

A. Add a cross-filter to the Opportunity source reports
Cross-filters are used to include or exclude related records (e.g., Opportunities with or without Cases), but they don’t resolve filter mismatches caused by missing equivalent fields.

B. Use a custom report type for Accounts with or without Opportunities
This might help in building better reports, but it doesn’t directly address the issue of dashboard filter compatibility. The problem is not the report type — it’s the missing equivalent field.

D. Create a joined Accounts and Opportunities report for the components
Joined reports are useful for comparing data across objects, but they cannot be used in dashboards unless the dashboard is built using Lightning tables, and even then, they don’t solve filter mismatch issues.

🔗 Reference:
Salesforce Help: Dashboard Filters
Salesforce Trailhead: Reports & Dashboards for Lightning Experience

Explanation:

Dynamic Actions, which allow for conditional visibility of action buttons, are configured on the Highlights Panel component within the Lightning App Builder.
Enable Dynamic Actions: The administrator must first edit the Lightning Record Page in the Lightning App Builder. They then select the Highlights Panel component and check the "Enable Dynamic Actions" checkbox in the properties panel.
Add Actions and Filters: After enabling Dynamic Actions, the administrator can add actions and configure their visibility. For this scenario, they would add the required action buttons to the Highlights Panel and then add a filter to each action.
Set Conditional Visibility: The filter would be set to reference the field that defines whether a planet is gaseous. For example, the action would be visible only when the "Is Gaseous" checkbox is True, and hidden when it is False.

Why the other options are incorrect

A. Record Detail:
The Record Detail component displays all fields based on the assigned page layout and does not support conditional visibility for individual action buttons. It is replaced by Dynamic Forms for field-level visibility control, but Dynamic Actions are a separate feature configured elsewhere.
C. Activities:
The Activities component (which includes the Activity Timeline) is used to track and manage tasks, events, and other interactions. It is not used for configuring dynamic action buttons on the record header.
D. Related Lists:
The Related Lists component displays related records in a list format. While actions can be configured for each related list, they are not the central action buttons displayed in the record header, which is where Dynamic Actions are typically configured.

Explanation:

Why D is correct:
A Custom Permission is a defined "flag" or "switch" that can be declaratively assigned to users via Permission Sets or Profiles. The key requirement here is the need for frequent updates to which users are included. The Apex trigger can be written to check for the presence of this custom permission before executing the automated process. This creates a perfect hybrid model:
Code (Apex Trigger): Contains the core, complex business logic.
Declarative Control (Custom Permission): An administrator can easily control who the process affects by adding or removing the custom permission from users' permission sets, without ever touching the code. This satisfies the requirement for declarative control over execution.

Why A is incorrect:
"Process Automation Settings" in Setup is used to globally activate or deactivate specific types of automation (like Processes and Flows). It is not a granular tool for controlling automation for specific users or profiles on a frequent basis.

Why B is incorrect:
A standard System Permission (like "API Enabled" or "Modify All Data") is too broad and inflexible for this purpose. Creating a new system permission is a complex development task, and they are not intended for this kind of custom, application-level business logic control. They are for granting fundamental system access.

Why C is incorrect:
Apex Class Access in a Permission Set controls whether a user can execute the Apex class at all (e.g., via a Visualforce page or Aura component). It does not control whether an Apex trigger fires for that user's DML operations. A trigger is system-generated code that runs based on database events, not user permissions to execute a class. If a user has permission to create/update a record, the trigger will fire regardless of their Apex Class Access settings. Therefore, this method cannot be used to conditionally control trigger logic.

Reference:
Salesforce Help: Custom Permissions
Apex Developer Guide: Checking Custom Permissions in Apex - The FeatureManagement.checkPermission() method is used for this exact purpose.
Trailhead: Custom Permissions for Lightning Apps and Apex

Explanation:

Why B is correct

Immediate lockout without cleanup prerequisites.
Freezing a user instantly blocks new logins. It’s explicitly meant for situations where you need to stop access now, but you can’t yet deactivate because the user is still referenced by automations (email alerts, approvals, scheduled jobs, etc.). Salesforce’s own guidance says: if something prevents deactivation, freeze the account to prevent logins while you fix the blockers.
Deactivation is likely blocked in this scenario.
This user is the sole recipient of 57 Email Alerts. That is a classic blocker for deactivation; Salesforce documents that some conditions prevent deactivation and in those cases you freeze first. You then update automations (replace recipients, change running users, reassign ownership) and deactivate later.
Freezing is designed for “needs more work before deactivation.”
Salesforce’s help article literally describes freezing a user as the right move when “the user account requires more work before deactivating.” That is exactly what you have here (57 alerts + 4,000 owned records).
Security first, business continuity second.
Freezing immediately cuts access but doesn’t break automations or require you to change ownership first. Later—once email alerts are re-pointed and ownership is transferred—you can deactivate to free the license. (Salesforce also reiterates that users aren’t deleted; they’re deactivated when ready.)

Why the other options are incorrect

A. Uncheck the Lightning User checkbox
That control only governs Lightning Experience UI access. It does not globally revoke the user’s ability to log in (e.g., via Classic or API if otherwise permitted). It’s not a lockout mechanism and therefore doesn’t meet “immediately remove all access.”
C. Set the login hours to ‘None’
Login Hours are profile-level, not user-level. Changing them would affect every user on that profile (collateral damage). Also, login hours prevent new logins outside the window but don’t forcibly end any existing sessions—so it’s neither targeted nor an immediate kill-switch.
D. Delete the user
You can’t delete users in Salesforce. The supported path is freeze (if deactivation is blocked), then deactivate once blockers are resolved. Deletion isn’t allowed due to audit/history integrity.

What to do next?

Freeze now to stop all new logins.
Remediate blockers: replace them on Email Alerts (use queues/roles/shared mailboxes), reassign any scheduled jobs/approvals, and transfer ownership of the ~4,000 records. (Salesforce acknowledges deactivation is blocked by such references; fix them after freezing.)
Deactivate the user once cleanup is complete (frees license; preserves audit history).

Bottom line:
Only Freezing (B) provides the immediate, targeted lockout required here, exactly as Salesforce recommends when deactivation is temporarily blocked by automation references.

Explanation:

A cross-object formula field on the Case object can reference the Account's "Status" field (or equivalent) via the standard Account lookup relationship, dynamically displaying the current value on the Case page layout without storing duplicate data. This value is formula-based, so it's immediately usable in Case validation rules (e.g., Account.Status__c != 'Active' to enforce rules based on Account status), ensuring real-time accuracy for the Service team.

Why B is incorrect:
A picklist field on Case would require manual selection or mapping, leading to data entry errors and inconsistency with the Account's actual status. It doesn't automatically pull or sync the value from the parent Account.

Why C is incorrect:
Rollup summary fields aggregate data from child records to a parent (e.g., count of Cases per Account), not the reverse. They can't pull a simple field value from parent to child for display or formula use.

Why D is incorrect:
The Case object already has a standard lookup to Account, but adding another lookup wouldn't display the specific Status field—it's just the relationship. It doesn't provide the readable, formula-accessible value needed on the page or in rules.

References
Salesforce Help: Cross-Object Formulas (details creating formulas that reference parent fields like Account Status for child objects).
Trailhead: Data Modeling with Relationships module, covering cross-object formulas for displaying and leveraging parent data in child contexts.