Explanation:

The IT manager needs a summary of the overall security posture or "health" of the organization's Salesforce instance.

D. Run a Health Check to identify vulnerabilities.
Salesforce Health Check is a standard feature designed precisely for this purpose. It provides a comprehensive, centralized summary of potential security vulnerabilities (such as weak password policies, excessive permissions, or insecure session settings) against a standard baseline (like the Salesforce Baseline Standard or a custom baseline). It gives an immediate health score and actionable steps to improve security, providing the exact summary the IT manager is looking for.

Why other options are incorrect:

A. Change the Organization-Wide Default to private to restrict visibility.
This is an action to change security settings, not a tool to summarize the current security health or audit the system.

B. Turn on Event Monitoring to track user events.
Event Monitoring provides detailed logs of user activity (e.g., when they logged in, what reports they ran, etc.). This data needs significant analysis and doesn't provide a high-level security health summary of the org's configuration and policies like Health Check does.

C. Download the last six months of user login data.
Login data is a small part of a security audit (focusing on who logged in and when), but it doesn't summarize the overall configuration, permissions, object access, or system vulnerabilities, which is what the Health Check tool provides comprehensively.

Explanation:

The Highlights Panel in Lightning Experience displays fields from the Compact Layout, not from the standard page layout. Here's how it works:

🧩 B. In the Account object manager, create a custom compact layout ✅
To show a field in the Highlights Panel, you must:
Go to Object Manager → Account → Compact Layouts
Create or edit a compact layout
Add the custom text area field to the layout
Set it as the primary compact layout via the Compact Layout Assignment
This ensures the field appears in the Highlights Panel across Lightning pages.

❌ Why the Other Options Don’t Work:
A. Create a new page layout and a new section titled highlights panel
The Highlights Panel is not a section in page layout — it’s controlled by the Compact Layout, which is a separate configuration.
C. From the page layout editor, drag the field to the highlights panel
You cannot drag fields into the Highlights Panel from the page layout editor.
That panel is populated only via the Compact Layout.
D. Make the field required and move it to the top of the page
This affects the page layout, not the Highlights Panel.
Required fields are enforced during record creation/editing, but this doesn’t control visibility in the Highlights Panel.

🔗 Reference:
Salesforce Help: Compact Layouts
Trailhead: Customize a Salesforce Object

Explanation:

The three sales-specific standard Lightning components that meet this requirement are:
C. Assistant
D. Key Deals
E. Performance Chart

C. Assistant
This component uses Einstein AI to provide a personalized list of leads and opportunities that need the user's immediate attention. This is the ultimate "insights at the start of each day" component, as it surfaces:
* Overdue tasks.
* Opportunities with no activity.
* New leads assigned to the user.

D. Key Deals
This is a highly customizable list view component that allows the manager to quickly view critical Opportunities, such as:
* Deals closing this month.
* Opportunities over a certain amount.
* The sales team's biggest deals in the pipeline.

E. Performance Chart
This component provides a visual, real-time tracking of the user's (or manager's team's) sales metrics, specifically focused on Opportunities. It typically shows: * Closed-Won amount vs. Goal.
* The current pipeline amount.
* Customizable metrics for the current sales quarter.

❌ Incorrect Answers and Why

A. Activities
While activities are crucial for productivity, the standard Today's Tasks or Today's Events components are what actually show the user's scheduled work for the day, not a generic "Activities" component (which is more common on a record page). The other options offer higher-level insights as requested by the manager.

B. Path
The Path component is designed to be on a Record Page (like an Opportunity or Lead) to guide a user through a process. It is not suitable for the Home Page, which is an aggregate of data, not a single record view.

Explanation:

The requirement is to temporarily reroute approval requests to another person (a backup manager) while the primary approver is unavailable. This is the specific function of the Delegated Approver feature.

Let’s break down each option:

A. Delegated approver
Correct. The administrator (or the sales manager themselves, if they have the right permissions) can set up a Delegated Approver. This allows the sales manager to designate a backup manager and specify a start and end date for the delegation. During this period, any approval requests assigned to the sales manager will be automatically rerouted to the backup manager. This is the standard, out-of-the-box solution for this exact scenario.

B. Two step Approval process
Incorrect. A two-step approval process is for creating a sequential workflow where a record must be approved by one person and then another. It is a static process design, not a temporary override for a single approver's absence.

C. Approval history related list
Incorrect. The Approval History related list is a log that shows the path a record has taken through an approval process. It is for viewing historical data, not for managing or redirecting active approval requests.

D. Delegated Administrator
Incorrect. A Delegated Administrator is a user who has been granted permission to manage specific setup tasks for a particular group of users, such as resetting passwords or managing public reports. This is a system administration role and is not related to the approval process for business records.

Summary:
The Delegated Approver feature is the correct tool for temporarily assigning a user's approval responsibilities to another person during a planned absence.

Reference:
Salesforce Help: "Delegate Your Approval Requests"
This documentation explains how a user can delegate their approval requests to another user for a specified time period, which directly fulfills the requirement.

Explanation:

A. Filter the component visibility with User > Profile > name = Sales User.
The requirement specifies that the component should only be visible to the "sales team," which in Salesforce is typically managed by a specific Profile (e.g., "Sales User" or "Sales Profile") or a Permission Set. Using the User's Profile is the standard, reliable way to target a group of internal users for component visibility.

B. Filter the component visibility with Form Factor = Phone.
The requirement explicitly states that the component should only show when users "are on their mobile phones." The Form Factor is the component visibility filter that allows you to specify the device type accessing the record page (Desktop, Phone, or Tablet). Setting it to Phone ensures the component is hidden on a desktop/laptop browser.

The Solution:
To meet both requirements, you would add two separate filters to the component visibility settings on the Lightning App Builder:
Filter 1: Field: User > Profile > Name, Operator: Equals, Value: Sales User
Filter 2: Field: Form Factor, Operator: Equals, Value: Phone

You would then set the filter logic to AND, ensuring that both conditions must be true for the component to appear.

❌ Incorrect Answers Detail:
C. Filter the component visibility with view = Mobile/Tablet.
The filter condition is Form Factor, not "view." While "Mobile/Tablet" sounds correct, it is not the actual visibility filter option available in the Lightning App Builder. The available values are typically Desktop, Phone, and Tablet.

D. Filter the component visibility with User > Role > Name = Sales User.
While a Role can be used to categorize users, a Role is primarily for defining the hierarchy of data access (sharing rules), not for defining a user's type (like "sales user"). In Salesforce, a user's functional job type (and their permissions/access to features) is correctly defined by their Profile or a Permission Set, making the Profile filter (Option A) the standard and correct choice here.