Explanation:

A  Template-triggered prompt flow is the correct type of flow to use for grounding a Prompt Builder prompt with related data. When building a Field Generation prompt template that populates a custom field on a Contact record page with a summary of the Contact's most recent Orders, the App Builder must create a flow that retrieves the relevant Order data and passes it to the prompt template as context. Template-triggered prompt flows are specifically designed to gather and prepare Salesforce data, including related records, to ground prompts with accurate, current information before the prompt is executed.

❌ Why Other Options Are Incorrect

B. Record-triggered flow – This is incorrect because record-triggered flows run automatically when a record is created, updated, or deleted. Although they can retrieve related data, they are not the specific flow type designed to provide dynamic context to a Prompt Builder template. For grounding a Field Generation prompt, a Template-triggered prompt flow is the appropriate choice.

C. Schedule-triggered flow – This is incorrect because schedule-triggered flows run according to a defined schedule and are intended for processing records at scheduled times. They are not designed to execute on demand when Prompt Builder needs contextual information for a specific Contact record.

D. Autolaunched flow – This is incorrect because an autolaunched flow can be invoked by other automation and can retrieve related records, but it is not the specific flow type designed for grounding Prompt Builder templates. Template-triggered prompt flows provide the required integration between Flow and Prompt Builder for supplying contextual data.

📚 References:

Salesforce Help – Prompt Builder – Explains how Template-triggered prompt flows can retrieve and prepare Salesforce data to ground prompts with relevant and context-aware information.

Explanation:

This formula correctly evaluates to TRUE when two conditions are met. First, it uses the  ISPICKVAL() function to check whether the picklist field `StageName` is exactly "Negotiation/Review". Picklist values must be enclosed in double quotes. Second, it checks `CloseDate - 7 = TODAY()` to determine whether the Close Date is exactly 7 days from today, meaning one week away. The  AND() function requires both conditions to be TRUE for the checkbox formula to return TRUE.

❌ Why Other Options Are Incorrect

A. AND(StageName = "Negotiation/Review", CloseDate - DAY(7) = TODAY()) – This is incorrect because `StageName = "Negotiation/Review"` is not the appropriate way to compare a picklist value in a Salesforce formula. The  ISPICKVAL() function should be used instead. Additionally, `DAY(7)` is not the correct function for subtracting seven days. The date arithmetic should use `CloseDate - 7`.

C. AND(StageName = 'Negotiation/Review', CloseDate = TODAY() - 1) – This is incorrect for several reasons. First, it does not use  ISPICKVAL() to evaluate the picklist. Second, `TODAY() - 1` checks for a Close Date of  yesterday, not seven days from today. Third, the picklist value is enclosed in single quotes rather than the required double quotes.

D. AND(ISPICKVAL(StageName, "Negotiation/Review"), CloseDate = DAY(7) - TODAY()) – This is incorrect because `DAY(7) - TODAY()` is invalid date arithmetic. The  DAY() function extracts the day-of-month from a date; it does not represent a number of days to subtract. The correct date calculation is `CloseDate - 7 = TODAY()`.

📚 References:

* Salesforce Help – ISPICKVAL Function – Explains that `ISPICKVAL()` is used to compare picklist field values in Salesforce formulas and provides guidance on working with picklist values.

Explanation:

The issue is caused by the  Allow reparenting checkbox being  unchecked on the master-detail relationship between Contact (parent) and Service Plan (child). When this checkbox is unselected, child records  cannot be reparented to a different parent record after creation. Since each Service Plan must be associated with one Contact, and reps need to change the Contact if the wrong one is selected, the relationship must allow reparenting. Therefore, the Allow reparenting option must be enabled so reps can change the Contact association after the Service Plan is created.

❌ Why Other Options Are Incorrect

A. The Read Only radio button, Allows users with at least Read access to the Master record to create, edit, or delete related Detail records, is selected – This is incorrect because the "Read Only" setting controls whether users with sufficient access to the master can create, edit, or delete related detail records. It does not control whether an existing child record can be reparented to a different master record.

C. The Read/Write radio button, Allows users with at least Read/Write access to the Master record to create, edit, or delete related Detail records, is selected – This is incorrect because the Read/Write setting controls users' ability to create, edit, or delete child records. It does not determine whether the child record can be assigned to a different parent. Reparenting is controlled independently by the Allow reparenting checkbox.

D. The Allow reparenting checkbox, Child records can be reparented to other parent records after they are created, is checked – This is incorrect because if Allow reparenting were checked, reps would be able to change the Contact associated with an existing Service Plan. Since they cannot change the Contact, the checkbox must be unchecked.

📚 References:

Salesforce Help – Master-Detail Relationships – Explains the Allow reparenting option and how it determines whether child records can be reassigned to a different parent record after creation.

Explanation:

A change set is the correct deployment tool because it allows the App Builder to move  metadata components, such as custom objects, fields, page layouts, Apex classes, flows, and Lightning record pages, from a Developer sandbox to production. The App Builder creates an  outbound change set in the Developer sandbox, adds the required components, and uploads it to production. In production, the administrator deploys the  inbound change set, moving the components into the production org. This is a standard Salesforce method for deploying metadata between related orgs.

❌ Why Other Options Are Incorrect

A. Refresh the production org from the Developer sandbox to bring the new components into production – This is incorrect because production cannot be refreshed from a sandbox.  Sandboxes are refreshed from production, not the other way around. A sandbox refresh replaces the sandbox with a copy of production and is not a deployment mechanism for moving sandbox changes into production.

B. Have a DHR administrator manually recreate each component in production using Setup – This is incorrect because manually recreating components is  time-consuming and error-prone. It can also introduce differences between the sandbox and production configurations. Change sets provide a more reliable and repeatable way to deploy the required metadata components between related Salesforce orgs.

D. Create a managed package in the Developer sandbox and install it in production using the generated install URL – This is incorrect because managed packages are primarily intended for  distributing applications and components to other Salesforce organizations. They are not the standard approach for deploying metadata from a sandbox to its related production org. Change sets are designed specifically for this type of deployment.

📚 References:

Salesforce Help – Change Sets – Explains how change sets are used to deploy metadata components from one Salesforce org, such as a sandbox, to another related org, such as production.

Explanation:

The Dynamic Related List - Single component is the correct choice because it allows the App Builder to configure  sort order, such as sorting by a specific field, and  hide actions, such as New, Edit, or Delete, directly within the Lightning page editor. It provides more customization than standard related lists, including control over sorting, filtering, and which actions are available to users on the record page.

❌ Why Other Options Are Incorrect

A. Related Lists – This is incorrect because the standard Related Lists component does not provide the same configurable options for custom sorting and action visibility in Lightning Experience. It displays related records using the standard related-list configuration and does not provide the advanced controls available with Dynamic Related List - Single.

B. Related List - Single – This is incorrect because although the Related List - Single component displays one related list, it does not provide the same advanced controls for configurable sorting and hiding individual actions. The Dynamic Related List - Single component is designed specifically for greater customization of the related records displayed on the page.

C. Related List Quick Links – This is incorrect because Related List Quick Links provides navigation links to related lists rather than displaying the related records themselves. It is primarily a navigation component and does not provide the sorting or action-visibility controls required by the scenario.

References:

Salesforce Help – Dynamic Related List Components – Explains that Dynamic Related List components provide additional configuration options for filtering, sorting, and controlling the actions displayed on Lightning record pages.