Explanation:

The requirement has two key parts:

Trigger: When the Account’s shipping address is changed.
Action: Automatically update the shipping address on all open Orders related to that Account.

This is a background automation use case — no user interaction is required to decide whether to update; it should happen seamlessly when the Account address changes.

Why B is correct:
Autolaunched Flow (record-triggered, before/after save) runs automatically in the background.
Triggered on Account object → when Shipping Address fields are edited.
Uses Get Records to find all open Orders (e.g., Status != 'Completed') where AccountId = Triggering Account.
Uses Update Records to set ShippingStreet, ShippingCity, etc., from Account.Shipping... fields.
No screen → no user input needed → streamlined and automatic.
This meets the goal: “streamlined solution” → minimal clicks, automatic sync.

A. Autolaunched flow on the Order page
There is no “Order page” trigger. Flows don’t run on page context like that. Also, changing Account address wouldn’t trigger a flow on Order.
C. Screen flow on the Order page
Requires manual launch per Order → not streamlined. Rep would need to open each Order and run the flow — defeats automation.
D. Screen flow on the Account page
Still requires manual launch (click a button) → not automatic. Rep must remember to run it every time. Not streamlined.

Best Practice Notes:
Use a Record-Triggered Flow (After Save) on Account.
Condition: ISCHANGED(ShippingStreet) OR ISCHANGED(ShippingCity) etc.
Filter Orders: Status not in {'Completed', 'Shipped'}
Map Account → Order shipping fields using Update Records (with record collection).

Reference:
Salesforce Help: Record-Triggered Flows
Trailhead: Automate Your Business Processes → Record-Triggered Flows

Explanation:

Why:
In Flow, a checkbox field evaluates to a Boolean. To branch when High_Value_Customer__c = TRUE, configure the Decision outcome with:
Resource: {!High_Value_Customer__c}
Operator: Equals
Value: {!$GlobalConstant.True}
If true, route to the second screen (skip the first).

Why the others are wrong:

B. “Use the equals operator and “High Value Customer” as the value.”
Type mismatch: A checkbox stores True/False, not text. Comparing a Boolean resource to a Text literal like "High Value Customer" is invalid.
Wrong operand meaning: "High Value Customer" is the field label, not a value the field ever contains. A checkbox doesn’t hold the words “High Value Customer”—it’s either checked (True) or unchecked (False).

C. “Use the contains operator and {!$GlobalConstant.False} as the value.”
Operator not applicable: Contains is for Text or Collections (e.g., “Does this string include that substring?” or “Does this collection include that item?”). It doesn’t apply to Boolean fields.
Wrong logic anyway: The requirement is “skip the first screen when the checkbox is True.” Checking for False would do the opposite—even if the operator were valid (it isn’t).

D. “Use the contains operator and “High Value Customer” as the value.”
Operator not applicable (again): Contains doesn’t work with Boolean fields—only text or collections.
Meaningless comparison: You’d be looking for the string "High Value Customer" inside something. A checkbox doesn’t contain text; it’s just True/False. Also, using the field’s label string in a decision is never how you evaluate a checkbox’s value.

Explanation:

In Lightning Experience, the Related List on a record page (like Contact → Cases) can be customized in two key ways:

1. Lightning App Builder (Option C)
In Lightning pages, the related lists are displayed through the Related List component.
Salesforce offers two related list display types:
“Related Lists” (Standard) – shows all lists as tiles (non-editable columns).
“Enhanced List” – allows inline editing, sorting, and column customization.

2. Page Layout Editor (Option D)
The page layout controls which fields (columns) appear in each related list.
To show fields like Case Name, ID, Reason, Status, Creation Date, the admin must edit the Contact page layout, scroll to the Cases related list, and add the desired fields as columns.
This ensures the information brokers need is visible in the related list.

To display multiple columns and allow flexibility, the admin should edit the Lightning Record Page in the App Builder, select the Related List component, and set the “Related List Type” = Enhanced List.
This combination (Enhanced List + Proper Columns) gives users a rich, sortable, multi-column related list on the Lightning record page.

❌ Incorrect Options:

A. Use the page layout editor to change the related list type to Enhanced List
The page layout editor doesn’t control list type; it only controls which fields appear.
The related list type (Standard vs. Enhanced) is managed in the Lightning App Builder, not the layout editor.

B. Edit the Related List component in the Lightning App Builder and choose Related List as the related list type
Choosing “Related List” (instead of “Enhanced List”) limits users to basic, tile-based related lists — it doesn’t support multiple columns or sorting.

Summary:
To display specific Case information under a Contact record:
Add the desired columns (Case Name, ID, Reason, Status, Created Date) in the page layout editor.
Switch the related list type to Enhanced List in the Lightning App Builder for better visibility and functionality.
This ensures brokers can easily view and manage detailed Case data directly from the Contact record page.

Reference:
Salesforce Help: Customize Related Lists in Lightning Experience
Trailhead: Customize Record Pages with the Lightning App Builder

Explanation:

B. Related Record:
This component displays details of a related record (in this case, the parent Account record) directly on the current record's page (the Case page). Crucially, the "Related Record" component has a built-in feature to enable inline editing of fields directly within the component view, providing a "quick way to update the account status from the case layout".

D. Rich Text:
This component allows an administrator to display formatted text (e.g., bold font, specific color, large size) on a Lightning record page. When used with a Component Visibility Filter (a feature applied to the component, not a component itself), the message will only appear when the case meets the specified criteria (e.g., Record Type equals 'Critical'). This meets the requirement for a filtered, bold message.

Why other options are incorrect:

A. Related List:
Related lists display lists of related records (e.g., all Contacts related to an Account, or all open cases related to the Account). They do not display a single record's details in an easily editable format or display a filtered warning message.

C. Record details:
This component displays all fields from the main object in a standard layout format. It doesn't meet the filtered message requirement (which needs visibility filters) and isn't specifically designed for inline editing of a related object's status.

Explanation:

Why this works
You want to stop users from saving an Opportunity if they set Close Date to a day that is already past. A validation rule is the right tool because it checks the record at save time and blocks the save when your condition is true. You can also target only the sales team by checking their profile or role in the rule.
Example formula you can adapt:
AND(
CloseDate < TODAY(),
$Profile.Name = "Sales User"
)

Message to show users:
“Close Date cannot be in the past.”
If managers should be allowed to backdate occasionally, exclude their profile or a permission set in the rule. For example, wrap the profile test in a NOT for a “Sales Manager” profile, or use a custom permission to bypass the rule.

Why the others are not right

A. Assignment Rule
Assignment rules decide who owns a record when it is created or when you re-run assignment. They do not validate field values and they do not block saves based on dates.

C. Field-Level Security
Field-level security controls who can see or edit a field at all. It cannot enforce conditional logic like “Close Date must be today or later only for certain users.”

D. Approval Process
Approvals route records to approvers. They are not designed to stop users from entering a past date on a field. You would still need a validation rule to block the save before an approval starts.

Notes and tips
Add ISCHANGED(CloseDate) if you only want to block edits when someone is changing the date, not when they are saving other updates.
Consider using a Custom Permission in the rule so admins can grant a small set of users the ability to bypass the block without relying on profile names.

Reference:
Validation Rules let you enforce data quality by preventing saves when conditions are met.
Profiles, roles, and custom permissions can be referenced inside validation rules to target specific groups.