Explanation:
The requirement involves bulk deleting data from specific fields across 5,000 Lead records using a CSV file containing Record IDs and the fields to clear. Since the operation affects more than 50,000 records and requires explicitly setting fields to null, the appropriate tool must support bulk updates and provide an option to treat empty values as null updates. The Data Loader offers this capability with the "Insert Null Values" setting.

Correct Options:

C. Use Data Loader to update leads using the CSV file.
Data Loader is the recommended tool for bulk data operations involving up to 5 million records. It supports update operations and allows you to map CSV columns to Lead fields. Since you have Record IDs and field values (which will be blank in the CSV), Data Loader can process all 5,000 records efficiently in a single batch, making it the ideal choice for this volume.

D. Select Insert Null Values in Settings.
When using Data Loader to update records, you must check the "Insert Null Values" setting in the Data Loader settings menu. By default, Data Loader ignores blank fields in the CSV and does not update them. Enabling this setting ensures that empty fields in your CSV are interpreted as NULL values, which will clear the data from those fields in Salesforce. This is the critical step to successfully delete field data.

Incorrect Options:

A. Select the correct record type.
Record Type selection determines which record type is assigned to new records or updates. However, for this requirement of clearing field data, record type is irrelevant unless you are changing the record type itself. The data deletion operation focuses on field values, not the record type, so this step is unnecessary and does not contribute to meeting the requirement.

B. Use Import Wizard to update leads using the CSV file.
The Import Wizard is limited to a maximum of 50,000 records and does not provide the "Insert Null Values" option. It will ignore blank fields in the CSV file and leave existing data intact. Even though 5,000 records fall within its limit, the Import Wizard cannot properly handle the requirement to clear field data, making it unsuitable for this task.

Reference:
Salesforce Help: "Data Loader" – Trailhead Module: "Data Management" (Unit: "Use Data Loader to Insert, Update, or Delete Records"). Refer to the Data Loader settings documentation for the "Insert Null Values" option and its behavior with blank fields. Also refer to the "Import Wizard Limitations" for record and field update restrictions.

Explanation:
The service manager has two distinct requirements: preventing status reversion (backwards progression) and making fields required based on specific criteria. Both of these are data integrity rules that should be enforced at the database level before a record is saved. Validation rules are declarative tools designed precisely to enforce data quality and business logic by blocking saves that violate defined conditions.

Correct Option:

D. Validation rules
Validation rules can enforce both requirements simultaneously. To prevent reverting to an earlier status, a validation rule can check if the new status value is "less than" the current status (using a Status Category or picklist order). To make fields required conditionally, the rule can use ISBLANK() combined with specific criteria (e.g., ISPICKVAL(Status, "Escalated")). When conditions are met, the rule fires, displays an error message, and blocks the save, ensuring complete compliance.

Incorrect Option:

A. Approval process
Approval Processes automate record approval workflows requiring human review. While they can update fields upon approval, they are not designed to prevent users from changing statuses to previous values or to conditionally require fields on every save. They are for sequential review steps, not blanket data validation rules.

B. Dependent picklist
Dependent picklists control which values are available in a child picklist based on the selection in a controlling field. They filter available options but cannot enforce that a user cannot select a specific status value (like an earlier status). They also cannot make unrelated fields required based on criteria; they only control picklist filter behavior.

C. Case flow
A Flow (or Case Flow) is a powerful automation tool that can handle complex logic and orchestrations, often with screen elements for user guidance. However, for simple data validation rules like preventing invalid status changes and making fields required, a validation rule is much lighter, easier to maintain, and runs instantly on save. Using a Flow for this would be over-engineering.

Reference:
Salesforce Help: "Validation Rules" – Trailhead Module: "Data Validation" (Unit: "Create Validation Rules"). See also the documentation on "Validation Rule Formula Examples" for preventing status rollback using PRIORVALUE() and ISPICKVAL()

Explanation:
When activating a Lightning page in the Lightning App Builder, administrators have specific assignment options to control which users see the page. The activation wizard allows assignment at the app level combined with user profiles, setting it as a default homepage for specific apps, or making it the org-wide default. These options provide flexible targeting based on user access and application context.

Correct Options:

B. Assign the page to a combination of apps and profiles.
During activation, you can assign the Lightning page to specific apps (e.g., Sales, Service) and specific user profiles (e.g., System Administrator, Sales Representative). This allows granular targeting, ensuring only users with the right profile see the page when they access the assigned app. This is the standard method for controlling page visibility.

C. Make the page the default homepage for specific apps.
You can set the Lightning page as the default homepage for users when they open a particular app. For example, you can make it the default homepage for the Sales app but not for the Service app. This is a dedicated option in the activation wizard under "Default Homepage" assignments.

E. Make the page the org default.
You have the option to set the Lightning page as the organization-wide default. This means all users across the entire org will see this page unless overridden by more specific assignments (like app+profile assignments). This is a quick way to roll out a page globally.

Incorrect Options:

A. Assign the page to a combination of apps and permission sets.
Permission sets are not supported as assignment criteria when activating Lightning pages. Page assignments only work with profiles, not permission sets. While permission sets grant additional permissions, they cannot be used to target Lightning page visibility during activation.

D. Make the page the default homepage for specific roles.
Roles are not available as assignment criteria in the Lightning App Builder activation wizard. While roles control record-level access in the sharing model, they are not used for Lightning page assignments. Page visibility is controlled through apps, profiles, and org-wide settings only.

Reference:
Salesforce Help: "Assign Lightning Pages to Users" – Trailhead Module: "Lightning App Builder" (Unit: "Activate and Assign Lightning Pages"). Refer to the activation wizard documentation for the specific assignment options available.

Explanation:
The requirement is to conditionally show a component on an Account's Lightning Record Page based on data from a related Contact record. Salesforce Lightning App Builder provides native visibility filters that allow components to appear or hide based on record field values. When criteria involve a related object, an "Advanced" filter type must be used to traverse the relationship.

Correct Option:

D. Set the component visibility to display based on an advanced filter type, using the contact field(s) to Define the dynamic criteria
Lightning App Builder's component visibility filters include a "Filter Type" option. By choosing "Advanced," the App Builder can create filter logic that references fields from related records (e.g., Account > Contacts). This allows the component to dynamically render only when the specified Contact field criteria are met, exactly fulfilling the requirement without requiring code.

Incorrect Option:

A. Add a related record component to the page layout
Adding a related record component (like the "Related List" or "Related Record" component) only displays child records on the page; it does not control the visibility of other components based on criteria. It shows data but cannot hide or show itself or other components dynamically based on field values of related records.

B. Hide the component behind a tab on the page layout
Hiding a component behind a tab simply organizes the page layout visually. It does not conditionally control visibility based on data criteria. Users can still click the tab to view the component regardless of the related Contact's values, so this does not meet the dynamic display requirement.

C. Set the filter type on the component visibility to display based on user permissions, using custom Permission to define the dynamic criteria
Visibility based on user permissions (Permission Sets or Profiles) controls who sees the component, not when it appears based on record data. While this is a valid visibility rule, it does not evaluate field values on the Account or related Contact. Therefore, it cannot satisfy the requirement of dynamic display based on related contact criteria.

Reference:
Salesforce Help: "Define Component Visibility in the Lightning App Builder" – Trailhead Module: "Lightning App Builder" (Unit: "Set Component Visibility"). Refer to the "Advanced Filter" section for traversing lookup relationships in visibility rules.

Explanation:
The requirement is to display the highest value from a set of child Offer records directly on the parent Property record. In Salesforce, when a Master-Detail relationship exists, the system provides a native declarative feature to aggregate child data (like SUM, MIN, MAX) onto the parent. This ensures real-time accuracy without requiring custom code or automation.

Correct Option:

A. Roll-up Summary
A Roll-Up Summary field is the perfect solution because it automatically calculates values (such as MAX, MIN, SUM, or COUNT) from child records on a Master-Detail relationship. By configuring it to calculate the MAXIMUM of the offer amount field on the Offer object, the Property record will always display the highest offer value. This calculation is maintained in real-time by Salesforce without any additional automation or manual intervention.

Incorrect Option:

B. Summary
"Summary" refers to report-level summaries or formula fields like "Parent Summary" which are used in reports or cross-object formulas, not as a field on a parent record. It does not create a stored field on the Property object. Since the requirement is to display the value directly on the Property record page, a Summary report alone would not solve this.

C. Text Area (Long)
A Long Text Area is a field type used to store large amounts of free-form text, such as comments or notes. It cannot perform any mathematical or aggregate calculations. Storing numeric offer values in a text field would also prevent any meaningful data analysis or reporting, making it entirely unsuitable for this requirement.

D. Multi-select Picklist
A Multi-Select Picklist allows users to select multiple predefined options from a list (e.g., property amenities). It is designed for categorization, not for aggregating or calculating numeric data from related records. This field type cannot compute the highest value from child records.

E. Rich Text Area
A Rich Text Area is used to store formatted text that includes bold, italics, links, or images. Like the Long Text Area, it is purely for textual content display and has no capability to perform calculations or summarize child record data. It would not meet the numeric aggregation requirement.

Reference:
Salesforce Help: "Roll-Up Summary Fields" – Trailhead Module: "Data Modeling" (Unit: "Create a Roll-Up Summary Field"). Refer to Salesforce documentation on Master-Detail relationships and standard aggregate functions.