Agentforce-Specialist Practice Test Questions

Explanation

UC’s problem is:
They’re seeing an increase in contract cancellations.
They want to proactively identify customers likely to cancel.

This is the textbook definition of customer churn prediction:

✅ Customer churn prediction identifies customers at risk of leaving based on historical patterns in the data (e.g. usage, engagement, support cases, contract age).
✅ It allows companies to:
Trigger proactive outreach (e.g. loyalty offers, customer success engagement).
Retain customers before they churn.

Model Builder (in Einstein Studio) is explicitly designed for this type of use case:
You can build a predictive model that calculates a churn probability score.
You can then use that score to segment customers and trigger automated processes or personalized communications.

Hence, Option B is correct.

Option A (Product recommendation prediction) is incorrect:
That predicts which products a customer might want to buy.
It does not address churn or cancellations directly.

Option C (Contract Renewal Date prediction) is incorrect:
While knowing renewal dates helps with retention, it’s not the same as predicting whether the customer intends to cancel.
UC’s concern is customers actively canceling, not just when their contract ends.

Explanation

UC’s problem is:
New support reps are assigned existing, ongoing cases.
Reading through all case comments and history can be time-consuming and overwhelming.

This scenario is the exact use case for Einstein Work Summaries. Here’s why:

✅ Einstein Work Summaries:
Uses generative AI to analyze case comments, emails, activities, and related records.
Generates a concise, natural-language summary of the case history, including:

. Customer issue context.
. Actions already taken.
. Current case status.
. Next suggested steps.

It helps new agents quickly get up to speed without manually reading each comment, improving efficiency and consistency.

Hence, Option C is correct.

Option A (Einstein Copilot) is incorrect in this context:
Copilot can answer questions conversationally and help with tasks.
However, the specific feature for summarizing case details is handled by Work Summaries, not Copilot alone.

Option B (Einstein Sales Summaries) is incorrect:
Sales Summaries are designed for opportunities, leads, and sales activities, summarizing sales calls, meetings, and CRM notes.
They’re not built for support cases or service workflows.

Therefore, the solution UC’s new support reps should use is:
C. Einstein Work Summaries

🔗 Reference
Salesforce Help — Einstein Work Summaries Overview
Salesforce Blog — How Einstein Work Summaries Help Agents Save Time
Salesforce Release Notes — Einstein Work Summaries for Service Cloud

Explanation

Comprehensive and Detailed In-Depth Explanation: In Salesforce Data Cloud, a custom search index is created to enable efficient retrieval of data (e.g., documents, records) for AI-driven processes, such as grounding Agentforce responses. Let’s evaluate the options based on Data Cloud’s functionality.

Option A: A retriever that shares the name of the custom search index. When a custom search index is created in Data Cloud, a corresponding retriever is automatically generated with the same name as the index. This retriever leverages the index to perform contextual searches (e.g., vector-based lookups) and fetch relevant data for AI applications, such as Agentforce prompt templates. The retriever is tied to the indexed data and is ready to use without additional configuration, aligning with Data Cloud’s streamlined approach to AI integration. This is explicitly documented in Salesforce resources and is the correct answer.

Option B: A dynamic retriever to allow runtime selection of retriever parameters without manual configuration. While dynamic behavior sounds appealing, there’s no concept of a "dynamic retriever" in Data Cloud that adjusts parameters at runtime without configuration. Retrievers are tied to specific indexes and operate based on predefined settings established during index creation. This option is not supported by official documentation and is incorrect.

Option C: A predefined Apex retriever class that can be edited by a developer to meet specific needs. Data Cloud does not generate Apex classes for retrievers. Retrievers are managed within the Data Cloud platform as part of its native AI retrieval system, not as customizable Apex code. While developers can extend functionality via Apex for other purposes, this is not an automatic outcome of creating a search index, making this option incorrect.

Why Option A is Correct: The automatic creation of a retriever named after the custom search index is a core feature of Data Cloud’s search and retrieval system. It ensures seamless integration with AI tools like Agentforce by providing a ready-to-use mechanism for data retrieval, as confirmed in official documentation.

Explanation:

Einstein for Flow allows you to leverage prompt templates within Salesforce Flows, enabling generative AI responses to be used directly in automation.

Why Einstein for Flow is Correct:

1. Einstein for Flow enables Flow Builders to call LLMs (Large Language Models) using prompt templates.
2. You can pass flow variables to the prompt and then use the response in the flow logic, such as updating records, sending emails, or making decisions.
3. This is the officially supported way to integrate prompt template responses into Flows as part of Salesforce's native generative AI tooling.

Breakdown of Other Options:

A. Invocable Apex
❌ Incorrect – While technically possible (you could build an Apex class to call an LLM and expose it to Flow), this is not necessary or recommended when Einstein for Flow is available. It adds unnecessary complexity.

B. Flow Action
❌ Misleading/Incomplete – This is a vague term. While Einstein for Flow uses custom Flow Actions under the hood, just saying “Flow Action” doesn’t capture the full capability or explain the integration with prompt templates. Also, standard Flow Actions don't provide AI integration unless powered by Einstein features.

Explanation

Copilot Actions Page
Primary interface for managing all Copilot actions
"Use the Copilot Actions page to view, create, and manage actions for your copilot."

Record Page for Copilot Action
Edit specific action details and grounding
"Each action has its own record page where you can configure instructions, inputs, and outputs."

Copilot Action Library Tab
Browse and select from pre-built actions
"The Action Library provides reusable actions that can be assigned to your copilot."

Why Other Options Are Incorrect:

B. Global Actions
Global Actions are for page-level quick actions, not Copilot integration
"Global Actions appear across all pages in the global publisher layout."

C. Copilot Detail Page
Used for high-level settings, not action management
"The Copilot detail page shows basic information and activation status."

Implementation Note:
Always test actions in Sandbox first before deployment to production, as recommended in the Copilot Best Practices Guide.

Explanation

Let’s look at each option through the lens of which AI feature is used in Salesforce:

Option A — Time-to-close estimation

✅ This is a predictive AI task.

Estimating time-to-close is a classic predictive analytics use case.
Typically handled by tools like:
. Einstein Prediction Builder
. Machine Learning models via Model Builder
It doesn’t need Prompt Builder because it’s about generating numeric predictions, not natural language.

So A does NOT require Prompt Builder.

Option B — Sales contract summary

✅ This is a generative AI use case.

Generating a summary from a text-heavy document (like a sales contract) requires:
. Understanding long text
. Producing human-readable summaries
This is exactly the purpose of Prompt Builder, which:
. Lets you craft custom prompts
. Passes records or document content into the prompt
. Produces a generative text output (e.g. summary, recommendation, explanation)

Hence, B requires Prompt Builder because it’s all about generating text.

Option C — AI-generated lead score

✅ Also a predictive AI task.

Lead scoring uses:
. Einstein Lead Scoring
. Einstein Prediction Builder
It outputs a numeric score or classification for prioritization.
It does not involve generating natural-language text summaries or explanations via prompts.

So C does NOT require Prompt Builder.

Thus, the only improvement from these choices that requires Prompt Builder is:
B. Populate an AI-generated summary field for sales contracts.

🔗 Reference
Salesforce Help — Prompt Builder Overview
Salesforce Blog — Build Custom Generative AI Experiences with Prompt Builder
Salesforce Help — Einstein Prediction Builder Overview

Explanation

The scenario is all about verifying data masking in the Einstein Trust Layer. Let’s break it down:
The Einstein Trust Layer is designed to:

Detect sensitive fields (like addresses, names, PII).
Mask or tokenize those fields before sending data to a large language model (LLM).
Maintain logs of what was masked for auditing and compliance purposes.

✅ To verify that masking is working:
The Einstein Trust Layer generates an AI audit trail, which logs:

The original prompt.
The masked version of the prompt.
Responses from the LLM.
Which fields were masked and how.

Inspecting the AI audit trail is the correct way to confirm whether address data is indeed masked as intended. The logs provide visibility and evidence for security and compliance teams.

Hence, Option C is correct.

Option A (Enable data encryption on the address field) is incorrect:

Encryption protects data at rest or in transit but does not affect masking in prompts sent to an LLM.
Encryption doesn’t replace the Trust Layer’s masking capability.

Option B (Review the platform event logs) is incorrect:

Platform events capture system and business events (e.g. record updates, flows firing).
They do not contain Trust Layer masking logs or prompt content.

Therefore, the correct way to verify privacy for masked data in Einstein Trust Layer is:
C. Inspect the AI audit trail

🔗 Reference
Salesforce Help — Einstein Trust Layer Overview
Salesforce Blog — How the Einstein Trust Layer Protects Data Privacy
Salesforce Help — View Generative AI Audit Data

Explanation:

To test and validate multiple real-world user utterances before activating a custom Copilot action, the Copilot Builder is the right tool because:

Copilot Builder allows you to:

Simulate user inputs (utterances) to see how Einstein Copilot interprets them.
Test if the correct custom action is triggered based on different phrasings.
Refine the action’s intent mapping to improve accuracy before deployment.

Why Not the Other Options?

A. Model Playground:
Used for generic LLM testing (e.g., prompt tuning for Einstein Studio), not for validating Copilot action behavior.

B. Einstein Copilot:
This is the runtime environment where Copilot executes, not a tool for pre-deployment testing of utterances.

Steps to Validate Utterances in Copilot Builder:

1. Open Copilot Builder (Setup → Einstein Copilot → Copilot Builder).
2. Select the custom action you’re testing.
3. Enter sample user utterances (e.g., "Update my case status" vs. "Mark this case as resolved").
4. Verify if the correct action/flow is suggested.
5. Adjust training phrases or intent settings if needed.

This ensures the action activates only for relevant user requests in production.

Explanation

In Salesforce, Generative AI capabilities are controlled by specific permission sets. To use features such as generating summaries with AI, users need to have the correct permission sets that allow access to these functionalities.

Generative AI User Permission Set: This is a key permission set required to enable the generative AI capabilities for a user. In this case, the missing Generative AI User permission set prevents the user from seeing the generative AI-enabled field icon. Without this permission, the generative AI feature in the Competitor Analysis custom object won't be accessible.

Why not A?
The Prompt Template User permission set relates specifically to users who need access to prompt templates for interacting with Einstein GPT, but it's not directly related to the visibility of AI- enabled field icons.

Why not B?
While a prompt template might need to be activated, this is not the primary issue here. The question states that other users with the same profile can see the icon, so the problem is more likely to be permissions-based for this particular user.

For more detailed information, you can review Salesforce documentation on permission sets related to AI capabilities at Salesforce AI Documentation and Einstein GPT permissioning guidelines.

Explanation

Comprehensive and Detailed In-Depth Explanation: In Salesforce’s Einstein Studio (part of the Agentforce ecosystem), creating a custom retriever involves setting up a mechanism to fetch data for AI prompts or responses. The essential step is defining the foundation of the retriever: selecting the search index, specifying the data model object (DMO), and identifying the data space(Option A). These elements establish where and what the retriever searches:

Search Index: Determines the indexed dataset (e.g., a vector database in Data Cloud) the retriever queries.

Data Model Object (DMO): Specifies the object (e.g., Knowledge Articles, Custom Objects) containing the data to retrieve.
Data Space: Defines the scope or environment (e.g., a specific Data Cloud instance) for the data. Filters are noted as optional in Option A, which is accurate—they enhance precision but aren’t mandatory for the retriever to function. This step is foundational because without it, the retriever lacks a target dataset, rendering it unusable.

Option B: Defining output configuration (e.g., max results, field mapping) is important for shaping the retriever’s output, but it’s a secondary step. The retriever must first know where to search (A) before output can be configured.

Option C: This option includes advanced configurations (vector/hybrid search, filtering fields, ranking method), which are valuable but not essential. A basic retriever can operate without specifying search type or ranking, as defaults apply, but it cannot function without a search index, DMO, and data space.

Option A: This is the minimum required step to create a functional retriever, making it essential. Option A is the correct answer as it captures the core, mandatory components of retriever setup in Einstein Studio.