Agentforce AI practice questions

Apply a Sharing Rule to the Knowledge object based on the Agent's User profile.

Why it fails: Sharing rules in Salesforce govern record access for users, but they do not directly dictate the context of Agentforce retrieval. While profile-based access is a foundation, it is insufficient for filtering specific AI response capabilities without integrating the Agent Builder's specific Topic and Action configurations.

Configure a Permission Set specifically for the AI User with read-only access to all articles.

Why it fails: Granting broad read-only access to all articles fails to provide the granular filtering required for specific AI use cases. This approach lacks the ability to restrict by category or topic, potentially exposing sensitive information that the agent should not be authorized to surface to end users.

Update the Agent's system prompt to ignore any articles outside of HR policy.

Why it fails: Relying on system prompts for security enforcement is considered 'soft' security and is prone to prompt injection vulnerabilities. System prompts should be used for behavioral guidance rather than data access enforcement, as they do not provide a robust, programmatic way to restrict underlying data retrieval.

A custom Lightning Web Component to display the order status.

Why it fails: Lightning Web Components are primarily for rendering user interfaces in the browser. While they might display data resulting from an agent's action, they are not a functional requirement for the agent to retrieve or process the underlying data logic needed for order status inquiries.

A dedicated Permission Set license for the Agent user.

Why it fails: While permission sets are vital for governing access, a specific 'Permission Set License' is not a prerequisite for the agent to function. Standard object-level permissions and appropriate user profiles are sufficient to allow the execution of the agent actions once properly configured in the platform.

An API integration user with OAuth tokens.

Why it fails: API integration users with OAuth tokens are typically used for external system communication. For internal custom objects within the same Salesforce org, the agent functions directly through its internal system context and designated actions, making this configuration unnecessary for standard order status retrieval scenarios.

The agent is missing the necessary read permissions for the order object.

Why it fails: Permission issues would typically result in a runtime exception or an 'Access Denied' error rather than a failure to trigger the action based on the policy. The policy logic specifically manages execution flow based on intent confidence, not record-level security during the initial trigger phase.

The 'data_scope' is set to 'current_user' which restricts access to shared orders.

Why it fails: The data scope attribute defines the context for data retrieval but does not prevent the action itself from triggering. If the query were valid, the agent would still attempt to run the action, even if the result returned no records due to the scoped access restriction.

The fallback array is empty and preventing execution.

Why it fails: The fallback array in the exhibit clearly contains 'human_agent_handoff', meaning it is not empty. Even if it were empty, this would not stop the action from triggering if the confidence score met the threshold requirements; it would simply result in no defined fallback behavior.

The requirement to display a UI component to the end user.

Why it fails: Neither Apex nor Flow is responsible for rendering the UI in the agent's chat interface. Agent actions are purely for executing business logic; the UI presentation is handled by the Agentforce platform's chat container, making this factor irrelevant to the choice between Apex and Flow.

The number of users currently active on the Agentforce platform.

Why it fails: The number of active users does not influence whether you should choose Flow or Apex. Both can be scaled appropriately, and governor limits are applied per transaction regardless of total platform usage. The decision should be based on logic complexity and developer/administrator skill sets.

Granting the Agent user 'Modify All' access to ensure it can see all necessary data.

Why it fails: Granting 'Modify All' is a security violation, violating the principle of least privilege. An agent should only have the minimum necessary access to perform its functions. Broad permissions increase the blast radius if the AI is tricked into retrieving information it shouldn't have access to.

Including all company data in the Agent's knowledge base for faster retrieval.

Why it fails: This is a dangerous practice that increases the risk of data leakage. Only data intended for user consumption should be included in the knowledge base. Including sensitive or proprietary information in the agent's knowledge base makes it potentially accessible to customers, violating security and privacy standards.

Hard-coding API credentials in the Apex controller for data retrieval.

Why it fails: Hard-coding credentials is a major security flaw that exposes sensitive secrets. If the agent needs to access external systems, it should use Named Credentials or other secure authentication methods provided by Salesforce, which manage credentials centrally and securely, avoiding the risks associated with hard-coding.

The maxRetries parameter is set too high, causing the action to cache unauthorized query results from previous sessions.

Why it fails: Retry parameters dictate how many times an action attempts execution upon experiencing transient network or timeout failures. They have no impact on record-level sharing rules or user-based data visibility filters.

GroundingEnabled is set to true, which forces Data Cloud to merge disparate customer records into a single profile.

Why it fails: Grounding simply allows the LLM to use retrieved structured or unstructured data to formulate accurate answers. It does not alter database sharing rules or bypass security context configurations defined in flows.

The actionName uses an asynchronous invocable method that executes outside the active user session context.

Why it fails: Invocable flows executed by Agentforce run synchronously within the conversational thread to provide immediate answers. The security flaw stems from the explicit 'without sharing' execution mode rather than asynchronous processing.

Verify the agent has a dedicated User License assigned.

Why it fails: Agentforce agents do not require a standard user license; they operate using a service user context defined within the configuration. Requiring a dedicated user license is a misunderstanding of the architecture, as the system manages the agent's identity and permissions through specialized platform integration rather than standard seat-based licensing.

Install the Agentforce AppExchange package.

Why it fails: Agentforce is natively built into the Salesforce platform and does not require an external AppExchange package to function. Installing third-party packages is unnecessary for core agent functionality and could introduce compatibility issues. Administrators should use the native setup tools provided directly within the Salesforce platform instead of external installations.

Manually create an Apex class for every user interaction.

Why it fails: Creating Apex classes for every interaction is an inefficient anti-pattern. Agentforce is designed to leverage declarative tools, prompt templates, and pre-built actions. Custom Apex should only be used for complex logic that cannot be handled by standard flows or native action configurations, not for every routine user interaction.

Increase the number of conversational turns in the history.

Why it fails: Increasing conversation turns affects memory, not factual accuracy. If the agent is reading incorrect pricing, the source of the data or the instruction set is the root cause. Expanding history consumes more tokens and can lead to focus drift, which complicates the reasoning process instead of improving it.

Enable the agent to search the public internet for pricing.

Why it fails: Allowing an agent to search the public internet for sensitive business data is a security and compliance risk. Pricing should be derived from your internal Salesforce data. Relying on external sources introduces instability and inaccuracies, violating the principle of grounding the agent in the company's verified data sources.

The Flow action's input and output parameters to include a query for available slots.

Why it fails: While the Flow action could be designed to query availability, the agent's ability to provide information before invoking the action depends on its data sources. The Flow is used to create appointments, not to fetch availability. If the agent is providing incorrect info, it's likely because it lacks access to the Appointment data source, not because the Flow action is missing a query.

The Einstein Trust Layer data masking rules for the Appointment object.

Why it fails: Data masking rules are used to hide sensitive information from the large language model, not to provide real-time data. They do not affect the agent's ability to query current availability. If masking were applied to time slots, it would hide them, making the problem worse. The issue is about data retrieval, not masking.

The agent's language model temperature setting to reduce creativity.

Why it fails: Temperature controls the randomness of the model's responses, but it does not grant access to real-time data. Lowering temperature might make responses more deterministic, but the agent would still lack current availability data. The root cause is missing data source configuration, not model creativity. The administrator should focus on data access.

Set field-level security on the account number field so the agent's running user cannot read it.

Why it fails: Field-level security would block the agent from retrieving the account number at all, preventing identity verification. The requirement is to verify identity without revealing the full number, so the agent still needs read access to compare values. FLS is an all-or-nothing control and does not provide partial masking or redaction in the response.

Create a validation rule on the Account object that prevents the account number from being displayed in chat.

Why it fails: Validation rules enforce data integrity on record save, not on data displayed in a conversation. They cannot inspect or alter what an agent returns to a customer. Using a validation rule here would also risk blocking legitimate updates. The correct control must operate on the response path, which validation rules do not touch.

Add an instruction to the agent's system prompt telling it to mask account numbers before responding.

Why it fails: Instructions influence the large language model's behavior but are not a deterministic control. A model can still surface the full number under unusual phrasing or prompt injection. Compliance requirements need a hard guardrail, not a natural-language request. Instructions are best for tone and scope, not for guaranteeing that sensitive data is never emitted.

Implement a Flow that filters PII from the agent's responses before they are sent.

Why it fails: While a Flow could theoretically post-process responses, Agentforce does not natively support intercepting and modifying agent responses in real time with a Flow. This approach would require custom development and is not a standard feature for enforcing response content policies. It is overly complex and not the intended solution for this requirement.

Set the agent's user profile to restrict access to PII fields.

Why it fails: Restricting field-level access on the agent's user profile controls what data the agent can retrieve from Salesforce records, but it does not prevent the agent from including PII if that data is already available through other means or from user input. The agent could still echo PII provided by the customer, so this alone does not fully enforce the restriction.

Enable Data Masking on the agent's user profile.

Why it fails: Data Masking in Salesforce is used to obscure sensitive data in sandboxes and does not apply to real-time agent responses. It is not designed to filter PII from conversational output, and it operates at the data storage level, not at the agent's response generation layer. Therefore, it cannot enforce the required restriction in this scenario.

Flow action

Why it fails: Flow actions can make external callouts using HTTP Callout, but they may not provide the same level of control over sensitive data handling as Apex. Flows can store data in variables, which might inadvertently persist in logs or debug outputs. For strict non-storage of verification codes, Apex is more suitable due to its ability to handle data in memory and avoid logging sensitive information.

Prompt Template action

Why it fails: Prompt Template actions are used to generate text using generative AI and are not designed for secure external system interactions. They cannot make API callouts to verify a one-time code. This option is incorrect because it does not provide the necessary integration capabilities to meet the scenario's security and functional requirements.

Standard action

Why it fails: Standard actions in Agentforce are pre-built for common tasks like creating records or sending emails. They do not support custom external API calls for verifying a one-time code without storing it. This option is incorrect because it lacks the customization needed to securely interact with an external verification system.

Instructions

Why it fails: Instructions provide high-level guidance on the agent's persona, tone, and boundaries. They do not detail the exact sequence of questions and responses. For a structured conversation like greeting, asking for an order number, and providing status, more granular control is needed than instructions alone can provide.

Topics

Why it fails: Topics are used to categorize the agent's knowledge and actions, helping it understand what it can talk about. They do not define the step-by-step conversational flow or the specific responses. While topics are important for organizing capabilities, they are not the primary component for scripting the interaction in this scenario.

Actions

Why it fails: Actions are the tasks the agent can perform, such as querying a database or calling an API. They are triggered based on the conversation but do not define the conversational flow itself. While actions are essential for retrieving shipping status, they do not dictate how the agent greets the customer or asks for information.

Salesforce Optimizer.

Why it fails: Salesforce Optimizer is a tool used to analyze org-wide metadata, identify technical debt, and suggest best practices for configuration. It does not provide the capability to simulate conversational AI interactions or test the logic flow of an Agentforce agent in real-time.

Einstein Discovery Predictions.

Why it fails: Einstein Discovery is a tool for predictive analytics and machine learning insights on structured data. It focuses on identifying patterns and trends within datasets, rather than testing or simulating natural language conversational flows for AI agents.

Deployment Manager.

Why it fails: Deployment Manager is a tool for moving changes between environments, such as from sandbox to production. It handles the migration of metadata and configurations, but it lacks the functional testing capabilities required to simulate and validate agent interactions during the configuration phase.

Use a complex, multi-page instruction document to cover every possible edge case.

Why it fails: Over-complicating instructions with excessive detail can lead to model confusion and inconsistent responses. It is better to provide concise, high-level directives and rely on specific Action definitions to handle edge cases, ensuring the agent remains focused and maintains a professional, predictable interaction style.

Allow the agent to dynamically learn from user input to improve its tone over time.

Why it fails: Allowing an agent to dynamically 'learn' its persona from unvalidated user input introduces significant risks of bias and inappropriate behavior. Professional tone and boundaries must be strictly enforced via the system configuration, not left to the agent's unsupervised interpretation of user feedback or input.

Hard-code all possible responses into the Agent Builder to ensure perfect tone.

Why it fails: Hard-coding responses eliminates the benefits of generative AI and makes the agent rigid. This approach defeats the purpose of using a Large Language Model, as it restricts the agent to static scripts and prevents it from providing context-aware, natural-sounding responses to varying customer queries.

The flow is currently inactive.

Why it fails: If a flow were inactive, the error would typically be a 'Flow Not Found' or a specific runtime error indicating that the flow cannot be invoked, not a 403 Forbidden. The 403 status code is explicitly related to permission restrictions, not the activation status of the flow.

The flow has an invalid input parameter.

Why it fails: An invalid input parameter would typically trigger a validation error or a runtime exception rather than a 403 Forbidden status. The 403 error code is a security-related response indicating that the platform has denied access to the object, not that the object's input data was malformed.

The Agentforce platform is experiencing a service outage.

Why it fails: A service outage would typically result in a 5xx series error code (e.g., 503 Service Unavailable). A 403 Forbidden error is specifically tied to access control and permission configurations within the environment, confirming that the agent is authenticated but lacks the right to perform the action.

It requires less initial configuration time than traditional chatbots.

Why it fails: Agentforce often requires more thoughtful configuration regarding topics, actions, and security guardrails compared to simple, linear chatbots. While it is more powerful, the investment in defining the agent's instructions and integrating it with business logic is a significant, necessary part of the implementation lifecycle.

It is cheaper to implement because it doesn't use Salesforce data.

Why it fails: Agentforce is designed specifically to integrate with and leverage Salesforce data (like CRM records, Knowledge articles, etc.). Furthermore, implementing an AI-driven agent involves costs related to platform licensing and configuration, so it is not inherently 'cheaper' simply because of its architecture.

It prevents the need for any human involvement in support processes.

Why it fails: The goal of Agentforce is to augment human support, not necessarily to replace it entirely. Complex or sensitive cases will always require human intervention. Claiming it removes the need for all human involvement is inaccurate and ignores the critical role of human-agent handoff in support processes.

It serves as the authentication layer for external API calls.

Why it fails: Authentication for API calls is handled by Named Credentials and Auth Providers, not by Topics. Topics are purely functional containers for managing intent recognition and response logic, and they play no role in the security or authentication processes of the Salesforce platform.

It stores all customer interaction logs for auditing.

Why it fails: Interaction logs are managed by the platform's logging system, not by Topics. While a Topic identifies the intent behind a conversation, it does not function as a data storage solution for history or logs, and confusing these responsibilities would misrepresent the platform's architecture.

It determines the visual layout of the chat interface.

Why it fails: The visual layout of the chat interface is managed by the Embedded Service or Lightning Experience configuration. Topics are strictly focused on intent recognition and logic flow, and they have no impact on the appearance or UI components of the agent's chat interface.

To force the user to pay for premium support services.

Why it fails: The handoff feature is intended for service quality and customer satisfaction, not for monetizing support. It ensures that complex issues are handled by qualified personnel, which is a key tenet of high-quality customer experience strategy and has nothing to do with service pricing models.

To automatically terminate the chat session if it takes too long.

Why it fails: Terminating a chat session due to duration is a poor user experience practice. The handoff feature is designed to continue the conversation, not end it, by bringing in a human to resolve the query efficiently, thereby maintaining the quality of the customer support experience.

To allow the agent to learn from the human agent's responses in real-time.

Why it fails: While human interactions can be used to improve future performance, the primary purpose of the handoff is immediate service resolution. Real-time 'learning' from a human agent is not the immediate functional objective of the handoff, which is focused on customer support continuity and resolution.

By storing all user history in a long-term database record.

Why it fails: While logs may be stored for audit purposes, the context for a conversation is typically handled by passing session state within the LLM's context window. Storing every single turn in a database record for real-time context is inefficient and not how the generative AI model maintains session continuity.

By relying on browser cookies to save the user's session state.

Why it fails: Browser cookies are not reliable for server-side AI context management and are subject to security restrictions. The agent's conversation context must be managed on the server side by the Agentforce platform to ensure security, consistency, and compatibility across different user devices and browsers.

By periodically refreshing the agent's training model.

Why it fails: Refreshing the training model is a resource-intensive process that does not happen in real-time. It is not used for maintaining session context. Session context is handled by short-term message passing during the conversation, not by updating the underlying AI model's training data.