Free Agentforce Specialist Practice Test Questions

Explanation:

To combine data from multiple unrelated objects (standard and custom) in a prompt template, Universal Containers (UC) should:

Use a Flow with Prompt Template Integration

Why? Flows can:
Query multiple unrelated objects (e.g., Opportunity, Custom_Product_Spec__c).
Transform/format data (e.g., JSON, concatenated text).
Pass the processed data to the prompt template via merge fields.

Implementation Steps:

Create an autolaunched Flow to:
1. Query records from all required objects.
2. Structure the data (e.g., combine fields into a summary).
3. Call the prompt template with the merged data.

Trigger the Flow via Quick Action or Process Builder.

Why Not the Other Options?

A. "Custom object to connect records":
Overly complex. Requires maintaining a temporary object.

C. "Flex template with resources":
Flex templates don’t directly query objects—they rely on pre-processed inputs.

D. "Record Snapshot":
Snapshots only ground data from a single record, not multiple unrelated objects.

Reference:
Salesforce Help - Flows with Prompt Templates

Explanation:

Record Snapshots grounding in Salesforce's Einstein for Agentforce (or more broadly, for generative AI features in Salesforce) allows AI prompts to include real-time data from Salesforce records. To control which fields are included when grounding a prompt with a record snapshot, you use a field set.
Here's a breakdown of the options:

A. Configure page layout of the master record type
❌ Incorrect – Page layouts control UI, not AI data grounding. They don’t influence what data is used in prompt templates.

B. Create a field set for all the fields to be grounded
✅ Correct – Salesforce uses field sets to define which fields from the record are included in the prompt context. This is a key step when configuring Record Snapshots grounding for prompt templates.

C. Enable and configure dynamic form for the object
❌ Incorrect – Dynamic forms also relate to UI behavior and layout on Lightning pages. They don't control what data is used for AI grounding.

Explanation:

Comprehensive and Detailed In-Depth Explanation: Salesforce Agentforce provides various prompt template types to support AI-driven tasks, such as generating text or populating fields. In this case, UC needs a custom prompt template to populate a field with generated output, which directly aligns with the Field Generation prompt template type. This type is designed to use generative AI to create field values (e.g., summaries, descriptions) based on input data or prompts, making it the ideal choice for UC’s requirement.

Additionally, UC has enabled the Einstein Trust Layer, a governance framework that ensures AI outputs are safe, explainable, and auditable, capturing AI Audit data for monitoring adoption and identifying improvement areas. The consideration UC should review is whether Dynamic Fields is enabled. Dynamic Fields allow the prompt template to incorporate variable data from Salesforce records (e.g., case details, customer info) into the prompt, ensuring the generated output is contextually relevant to each record. This is critical for field population tasks, as static prompts wouldn’t adapt to record-specific needs. The Einstein Trust Layer further benefits from this, as it can track how dynamic inputs influence outputs for audit purposes.

Option A: Correct. "Field Generation" matches the use case, and "Dynamic Fields" is a key consideration to ensure flexibility and auditability with the Trust Layer.

Option B: "Field Generation" is correct, but "Dynamic Forms" is unrelated. Dynamic Forms is a UI feature for customizing page layouts, not a prompt template setting, making this option incorrect.

Option C: "Flex" templates are more general-purpose and not specifically tailored for field population tasks. While Dynamic Fields could apply, Field Generation is the better fit for UC’s stated goal.

Option A is the best choice, as it pairs the appropriate template type (Field Generation) with a relevant consideration (Dynamic Fields) for UC’s scenario with the Einstein Trust Layer.

Explanation

To include related Opportunities data in a prompt template, the AI Specialist should:

Use Merge Fields for Default Related Lists

Prompt templates support default related list merge fields (e.g., {{Account.Opportunities}}).
This dynamically pulls all opportunities tied to the Account without custom development.

Example:
"Summarize all opportunities for {{Account.Name}}: {{Account.Opportunities}}"

Why Not the Other Options?

A. Custom related list merge fields:
Unnecessary complexity. Default merge fields work for standard related lists. Custom retrievers are only needed for external/non-standard data.

C. Formula fields:
Formula fields cannot process related lists as input. They’re for single-record calculations.

Implementation Steps:

In Prompt Builder, create a new template.
Use the merge field {{Account.Opportunities}} to ground the prompt.
Add filters if needed (e.g., {{Account.Opportunities|filter:"StageName='Closed Won'"}}).

This ensures real-time, structured opportunity data in AI-generated summaries.

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

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: UC’s custom prompt for summarizing case records is underperforming, and we need to identify a likely cause. Let’s evaluate the options based on Agentforce and Einstein Generative AI mechanics.

Option A: The prompt template version is incompatible with the chosen LLM.Prompt templates in Agentforce are designed to work with the Atlas Reasoning Engine, which abstracts the underlying large language model (LLM). Salesforce manages compatibility between prompt templates and LLMs, and there’s no user-facing versioning that directly ties to LLM compatibility. This option is unlikely and not a common issue per documentation.

Option B: The data being used for grounding is incorrect or incomplete. Grounding is the process of providing context (e.g., case record data) to the AI via prompt templates. If the grounding data— sourced from Record Snapshots, Data Cloud, or other integrations—is incorrect (e.g., wrong fields mapped) or incomplete (e.g., missing key case details), the summaries will be inaccurate. For example, if the prompt relies on Case. Subject but the field is empty or not included, the output will miss critical information. This is a frequent cause of poor performance in generative AI and aligns with Salesforce troubleshooting guidance, making it the correct answer.

Option C: The Einstein Trust Layer is incorrectly configured. The Einstein Trust Layer enforces guardrails (e.g., toxicity filtering, data masking) to ensure safe and compliant AI outputs. Misconfiguration might block content or alter tone, but it’s unlikely to cause summaries to lack appropriate information unless specific fields are masked unnecessarily. This is less probable than grounding issues and not a primary explanation here.

Why Option B is Correct: Incorrect or incomplete grounding data is a well-documented reason for subpar AI outputs in Agentforce. It directly affects the quality of case summaries, and specialists are advised to verify grounding sources (e.g., field mappings, Data Cloud queries) when troubleshooting, as per official guidelines.

🔗 Reference
Salesforce Help — Grounding Prompt Templates with Record Snapshots

Explanation:

✅ Why C. Enable Dynamic Forms on Mobile is correct

For generative AI–enabled fields (like Agentforce responses, prompts, etc.) to be available in the Salesforce mobile app, those fields must actually render on the mobile record page.

Salesforce does this by using Dynamic Forms on Mobile:

1. Generative AI fields are usually dynamic, configurable fields on Lightning record pages.
2. When you enable “Dynamic Forms on Mobile” for that Lightning record page, Salesforce allows those dynamic field sections (including AI-enabled ones) to appear in the Salesforce mobile app.
3. Without Dynamic Forms on Mobile, the page layout used on desktop may not behave the same way on mobile, and the generative AI-enabled fields won’t be accessible to the user in the app.

So the key idea:

To see AI-enabled fields on mobile, you must let Dynamic Forms render on mobile → hence C.

❌ Why A. Enable Mobile Generative AI is wrong

. There is no standard Salesforce setup feature literally named “Mobile Generative AI”.
. Salesforce enables generative AI (Agentforce, Einstein features, etc.) through other settings: permissions, Einstein/Agentforce setup, enabling specific features, assigning permission sets, and configuring pages.
. Since “Enable Mobile Generative AI” is not a real config toggle, it’s a distractor.

❌ Why B. Enable Mobile Prompt Responses is wrong

Similarly:

1. There is no setup option called “Mobile Prompt Responses”.
2. “Prompt responses” describes what generative AI does (responding to prompts), but not an actual Salesforce mobile config setting.
3. Access to prompt-based AI features in mobile is controlled by:

. Permissions / licenses
. Enabling the feature org-wide
. Page configuration (Dynamic Forms on Mobile) to show the AI-enabled fields

So B is just a plausible-sounding name, but not a real configuration item you can enable in Setup.

Explanation:

Token limit errors occur when the input (including grounding data) exceeds the LLM's maximum token capacity. The random nature of these errors is due to:

Variable Record Data

The prompt template likely uses record data grounding (e.g., {{Record.Field}}).
If some records have more populated fields or longer text values, they consume more tokens, pushing the prompt over the limit.

Why Not the Other Options?

A. Switching to Flex Template:
While Flex templates offer more flexibility, they don’t inherently solve token limits. The issue is data-dependent, not template-type-dependent.

C. LLM Token Demand Variability:
Salesforce’s LLM allocates a fixed token limit per prompt (e.g., ~3000 tokens for GPT-based models). It doesn’t fluctuate with user demand.