Explanation:

This reflects the correct, standard execution model for Agentforce agents based on their deployment context:

Internal Employee Agents (e.g., Sales Productivity Agent used by internal reps) run in the context of the authenticated Salesforce user who is interacting with the agent. This means the agent's actions are constrained by that specific employee's existing permissions (profile, permission sets, sharing rules, field-level security, etc.) — the agent doesn't get elevated or separate access; it acts as the logged-in employee.

Customer-facing Service Agents deployed on Experience Cloud (or other external channels) run as a dedicated integration/system user — specifically, an Einstein Service Agent User — which has its own assigned permission set(s) configured by the admin/specialist. This dedicated user context is necessary because external/guest users on an Experience Cloud site don't have full Salesforce licenses or the same permission structure as internal employees, so a controlled, purpose-built service user is used to execute actions securely and consistently.

Why the other options are incorrect:
A. ❌ This is incorrect because the customer-facing Service Agent does not simply inherit the Experience Cloud guest user profile's permissions by default. Instead, it operates through the dedicated Einstein Service Agent User, which is specifically configured with its own permission set — this provides a controlled, purpose-built security context rather than relying on (and having to broadly configure) the guest user profile for all agent actions.

C. ❌ This is incorrect because it misrepresents the internal agent's execution model — internal Employee Agents run under the authenticated user's own permissions, not as a separate dedicated service user. Only the customer-facing agent uses the dedicated Einstein Service Agent User pattern.

Reference:
Salesforce Agentforce documentation — "Agent Security and Execution Context" (Employee agents run as the logged-in user; Service Agents on external channels run as the Einstein Service Agent User with a dedicated permission set).

Explanation:

This question tests your understanding of Salesforce's official framework for prompt engineering guidelines within Einstein Prompt Builder, often referred to as the RTCCF model (Role, Task, Context, Constraints, Format). The prompt requirements mapped to these constructs are as follows:

Task: Summarize customer case notes after a support call.

Context: Capture the customer’s issue, troubleshooting steps taken, and next actions.

Constraints: "Be no longer than five sentences", "use plain language with no technical jargon", and "if no next action is identified, explicitly state 'No next action required.'"

Format: Dictates how the resulting summary text block should look and behave based on the instructions provided.

Why the Other Options Are Incorrect
A. ❌ Role, Task, LLM Clarity Score, and Format
"LLM Clarity Score" is completely made up and is not a valid prompt construct or feature in Salesforce Prompt Builder.

B. ❌ Role, Task, Token Size Limit, and Format
While a prompt can have a role, "Token Size Limit" is a system threshold or boundary handled by the underlying LLM's architecture, not a functional writing construct designed by the service manager within Prompt Builder.

Reference
Salesforce Prompt Builder Best Practices Guide: Designing Effective Prompt Templates using the RTCCF Framework.
Trailhead: Prompt Fundamentals & Advanced Prompt Engineering in Salesforce.

Exam Tip
Salesforce officially frameworks prompt engineering around five pillars: Role, Task, Context, Constraints, and Format. Look closely at the choices for fake terminology (like Clarity Score) or system metrics (Token Limits) to quickly filter out incorrect answers.

Explanation:

The requirement is to ensure that responses generated by Salesforce's standard foundation models are consistently:
* Empathetic
* Professional
* Appropriate for customer support

The most effective prompt engineering technique is to provide the model with a clear role and behavioral instructions in the prompt, such as:

"Act as an empathetic customer support agent. Respond professionally, acknowledge the customer's concern, and provide a clear, helpful resolution."

This is a well-established prompt engineering practice known as role prompting (or assigning a persona). It guides the LLM's style and tone without requiring model customization or fine-tuning.

Why the Other Options Are Incorrect
A. ❌ Configure the prompt template tone with a dataset of past interactions...
Prompt Builder does not permanently alter the behavior of Salesforce's standard foundation models by supplying historical datasets.
Standard foundation models are not fine-tuned through Prompt Builder in this manner.
This option describes capabilities beyond standard prompt engineering.

C. ❌ Include multiple-choice picklist questions within the prompt template...
Multiple-choice questions are not a recognized technique for establishing response tone.
They add unnecessary complexity and do not reliably improve empathy or professionalism.
Prompt templates should provide clear instructions rather than quiz the model.

Reference
Salesforce Prompt Builder documentation on writing effective prompts and providing clear instructions.
Salesforce documentation on prompt engineering best practices for Agentforce.
Salesforce Certified Agentforce Specialist (AI-201) Exam Guide – Prompt Builder and prompt engineering.

Exam Tip
For AI-201, remember these prompt engineering principles:
✅ Assign a role/persona (e.g., "Act as a professional support agent.")
✅ State the desired tone explicitly (empathetic, concise, professional, friendly).
✅ Give clear instructions and context.

Avoid answers that imply you can train, fine-tune, or permanently modify Salesforce's standard foundation models through Prompt Builder, as Prompt Builder uses prompt engineering, not model retraining.

Explanation:

Salesforce Knowledge articles provide built-in versioning and publishing controls. When integrated into an Agentforce Data Library (ADL), the agent automatically retrieves the current published version of the article. This ensures customers always receive the most up-to-date information without requiring manual index rebuilds or custom version management.

Option A is incorrect:
File-based ADLs do not have native versioning; they rely on manual updates and index rebuilds.

Option B is correct:
Knowledge-based ADLs leverage Salesforce Knowledge’s native versioning, guaranteeing that only the latest published content is surfaced.

Option C is incorrect:
File-based ADLs do not automatically serve the latest content — they require manual intervention.

Reference:
Salesforce Documentation: Agentforce Data Library Types
Salesforce Help: Knowledge Article Versioning

Explanation:

Why A is correct:
When dealing with structured or tabular data (like tables, spreadsheets, or PDFs with complex layouts) within a Data 360 Document Ingestion Pipeline, the parser used during the ingestion process plays a critical role in how the document is chunked and vectorized.

The default parser in Data Cloud typically treats documents as plain text, chunking them based on semantic boundaries (like paragraphs or sentences). For tabular data, this approach can scatter related rows and columns across separate chunks, breaking the contextual relationships (e.g., a table header becoming disconnected from its data rows).

Docling is a specialized, advanced parser (developed by IBM and integrated into Salesforce Data Cloud) specifically designed to handle complex document structures—including tables, columns, rows, and hierarchical layouts. Docling preserves the structural integrity of tabular data, ensuring that when the document is chunked and vectorized, each chunk retains its full tabular context (headers with corresponding data rows).

By switching to the Docling parser, the specialist ensures that tabular information remains intact and contextually coherent during retrieval, resolving the issue of scattered, fragmented data.

Why B is incorrect:
An ensemble retriever is a technique used at query time to combine results from multiple retrieval strategies (e.g., keyword search + vector search) and re-rank them. It does not address how the data was originally chunked or parsed at ingestion time. If the chunks are already broken and scattered, an ensemble retriever cannot "stitch" them back together meaningfully because the original structural relationships were lost during ingestion. The issue must be fixed at the ingestion/parsing stage, not at the retrieval stage.

Why C is incorrect:
Switching the search index configuration to keyword search scoring (e.g., BM25 or TF-IDF) would change the ranking algorithm used for retrieval, prioritizing exact keyword matches over semantic relevance. This does not address the chunking/parsing issue at all. The data would still be scattered across chunks; the agent would just retrieve scattered chunks based on keyword matches instead of semantic similarity. This would make the problem worse, not better, and does nothing to preserve tabular context.

References:
Salesforce Official Documentation: "Data Cloud Document Ingestion and Parsing" – explicitly describes Docling as the recommended parser for complex documents containing tables, charts, and structured layouts, preserving tabular context during chunking.
Trailhead Module: "Ingest Unstructured Data into Data Cloud" > Unit: "Configure Document Parsers" – compares the default parser (for simple text) with Docling (for tables and complex layouts), advising the use of Docling when tabular integrity is required.