Explanation:

In Data Cloud (Data 360), when a retriever queries a search index that contains content from multiple sources (in this case, internal Knowledge articles and external partner portal content), it can leverage source metadata (fields like document type, source system, author, object type, etc.) that was preserved when the data was ingested and indexed. The retriever's filtering capability allows the specialist to:

* Distinguish which source (Knowledge vs. partner portal) contributed to a given retrieved chunk.
* Apply filters or boosts based on that metadata to refine which results are returned and how they're ranked (via semantic, keyword, or hybrid search).
* Troubleshoot conflicting answers by tracing retrieved passages back to their origin source.

This is the correct place to review/configure because the retriever is the component responsible for actually pulling ranked, filtered results from the index at query time — and metadata-based filtering at this stage is exactly how you'd identify and differentiate the origin of information causing conflicting answers.

Why the other options are incorrect:
A. Data harmonization process:
Harmonization is about mapping raw ingested data (DLOs) into standardized Data Model Objects (DMOs) — it happens upstream, before indexing/retrieval. While source metadata may originate here, harmonization itself is not the process used to differentiate sources during retrieval/troubleshooting — that's a retriever-level concern, not a harmonization-level one. Also, "hybrid retrievers" querying harmonized metadata isn't how this troubleshooting step is framed in Salesforce's model.

B. RAG synthesis phase:
This describes the LLM generation step where retrieved context is used to produce a final answer. The LLM doesn't "automatically append a source system tag" as a built-in synthesis behavior — source attribution needs to be established earlier, at the retrieval/metadata level, not assumed as automatic behavior of the generation phase. This option also misrepresents how RAG synthesis works.

Reference:
Salesforce Data Cloud documentation — "Retrievers in Data Cloud" (filtering retrieved results using metadata for source differentiation and troubleshooting grounding conflicts).

Explanation:

The requirement specifies a declarative solution to populate a single record field directly from the record page layout while allowing the end user to preview, regenerate, or manually modify the generative AI output before saving it to the database.

The correct prompt template type is explained below:

Field Generation prompt templates (configured within Einstein Prompt Builder) are specifically designed to enrich individual fields on a Salesforce record.

When an administrator links a Field Generation template to a field and exposes it via Lightning App Builder, a dedicated generative AI button appears adjacent to that field on the user interface.

Clicking this button opens an interactive inline popover window. Inside this overlay, users can preview the text generated by the LLM, click to regenerate an alternative response if needed, or explicitly manually edit the text block directly inside the field container before hitting Save.

Why the Other Options Are Incorrect
B. ❌ Flex
Flex prompt templates provide maximum architectural flexibility because they allow admins to define multiple custom inputs from different objects. However, they do not automatically bind to a single field layout out-of-the-box to provide the standard inline "preview, regenerate, and manual edit" field popup interface without custom component backing.

C. ❌ Sales Email
Sales Email templates are specifically reserved for compiling personalized outreach communications within email composers (such as Einstein Sales Emails). They are not used to update or enrich static field descriptions on a core object record like an Account.

Reference
Salesforce Prompt Builder Developer Guide: Create a Field Generation Prompt Template.
Salesforce Help: Einstein Generative AI Desktop User Experience for Field Generation.

Explanation:

Agentforce for Sales includes a library of standard, out-of-the-box agent actions designed for common sales use cases — and finding similar records (such as opportunities similar to a given one) is one of these pre-built capabilities. Salesforce provides a standard action (part of the standard Sales topics/actions, sometimes surfaced as something like "Identify Similar Opportunities" or via Einstein-powered similarity matching) that agents can use out of the box to respond to utterances like "Show me other opportunities like this one."

Since this is a common, well-supported sales use case, UC should first leverage the standard action rather than building custom logic — this aligns with Salesforce best practice guidance: always evaluate whether a standard action meets the business requirement before building custom actions (via Flow or Apex), since standard actions are pre-built, tested, maintained by Salesforce, and require less implementation effort.

Why the other options are incorrect:
B. Create a custom Agent action calling a flow:
This is unnecessary custom development effort when a standard action already exists for this exact use case. Building a custom flow-based action would only be appropriate if no standard action met the requirement.

C. Create a custom Agent action calling an Apex class:
Same reasoning as B — Apex-based custom actions are appropriate for more complex, unsupported logic, not for a capability already available as a standard action. This adds unnecessary complexity and maintenance overhead.

Reference:
Salesforce Agentforce for Sales documentation — "Standard Actions for Sales Topics" (includes similarity-based opportunity discovery as a pre-built standard action).

Explanation:

The issue is caused by Salesforce security, not by the Flow logic.

The Opportunity object has an Organization-Wide Default (OWD) of Private, so the Einstein Service Agent User cannot see Opportunity records unless it has both:
* The necessary object permissions (such as Read access).
* Appropriate record-level access, provided through sharing rules, role hierarchy, or another sharing mechanism.

Granting only the minimum permissions and sharing required follows the principle of least privilege, which states that users should receive only the access necessary to perform their tasks.

Why the Other Options Are Incorrect
B. ❌ Set the agent action flow to run in System Mode without sharing.
Running a Flow in System Mode bypasses normal user-level security for execution.
While this may allow access to the records, it grants broader privileges than necessary and does not adhere to the principle of least privilege.
For exam questions emphasizing security best practices, avoid bypassing sharing unless there is a specific business requirement.

C. ❌ Change the Opportunity object's organization-wide default to Public Read Only so the Einstein Service Agent User can access records.
Changing the OWD affects all users in the organization.
This unnecessarily broadens access and violates the principle of least privilege.
OWD should not be relaxed simply to solve access for a single agent.

Reference
Salesforce documentation on Organization-Wide Defaults (OWD) and record-level security.
Salesforce documentation on Flow execution context (User Mode vs. System Mode).
Salesforce Agentforce documentation on configuring permissions for the Einstein Service Agent User.
Salesforce Certified Agentforce Specialist (AI-201) Exam Guide – security and access control for Agentforce.

Exam Tip
Questions that mention "principle of least privilege" almost always favor granting targeted permissions rather than bypassing or relaxing security.

Think of the options in this order:
✅ Permission Sets + Sharing Rules → Grant only the required access (best practice).
⚠️ System Mode → Bypasses security; use only when explicitly required.
❌ Relax OWD or broad org-wide access → Usually the least secure option and rarely the correct exam answer.

Explanation:

Prompt Builder is the Salesforce AI capability designed to generate contextual insights directly on record pages. It allows admins and specialists to define prompts that leverage CRM data (such as guest profiles, interests, and activity preferences) to produce summaries, recommendations, or other AI-driven outputs. These outputs are scoped to appear only where configured — in this case, the contact record page.

Option A (Flow Builder) is incorrect:
Flow Builder automates business processes but does not generate AI-driven summaries or recommendations.

Option B (Agentforce Builder) is incorrect:
Agentforce Builder is used to design conversational AI agents, not record-specific summaries.

Option C (Prompt Builder) is correct:
Prompt Builder enables contextual AI outputs tied to Salesforce records, exactly matching the requirement.

Reference:
Salesforce Documentation: Prompt Builder Overview

Trailhead Module: AI Prompt Builder Basics

Salesforce Help: Using Prompt Builder for Record Pages