Agentforce Specialist Interview Questions

Agentforce is Salesforce's AI agent platform built natively on the Salesforce platform. Its core components are: (1) Agent Builder: The declarative UI in Setup where you define, configure, and test agents. You specify the agent's role, available Topics, and assigned Actions without writing LLM prompts directly. (2) Topics: The high-level capability domains the agent can handle (e.g., "Order Management", "Lead Qualification"). Each topic has a natural language description that the Planner uses for classification. (3) Actions: The individual tasks the agent executes within a topic — implemented as Flows, Apex @InvocableMethod, Prompt Templates, or Knowledge retrievals. (4) Planner / Orchestrator: The LLM-powered reasoning engine that interprets user intent, selects the appropriate Topic, determines which Actions to invoke, and sequences multi-step execution using the ReAct pattern. (5) Einstein Trust Layer: The security and compliance wrapper around all LLM interactions — handling data masking, zero data retention, toxicity screening, and audit logging before data leaves Salesforce.

An Agent Topic defines a coherent domain of capability for the agent, grouping related Actions that serve a common user goal. Each topic has: (1) Label: The internal name (e.g., "Case Management"). (2) Description: Natural language text consumed by the Planner to classify which topic applies to a user's request. This is critical — a poorly written description causes misclassification. (3) Scope: Clarifies what this topic does and does not handle, preventing overlap with other topics. (4) Actions: The list of Actions assigned to this topic. A well-written description: uses clear, specific language about the user intent it addresses ("Use this topic when the user wants to create, update, or escalate a support case"); explicitly excludes adjacent intents ("Do not use this topic for billing questions — see the Billing topic"); is written from the user's perspective, not a technical description of the implementation. A single agent can have multiple topics, and the Planner's classification accuracy depends entirely on the clarity and non-overlap of these descriptions.

Agentforce supports four primary action types: (1) Flow Actions: Auto-launched Flows invoked by the agent. Best for multi-step processes involving data retrieval, record creation/update, or conditional logic that an admin can build declaratively. The agent passes input variables and receives output variables. (2) Apex @InvocableMethod Actions: Custom Apex methods annotated with @InvocableMethod. Used when Flow cannot handle the required complexity — calling external APIs, complex data transformations, or performance-sensitive operations. Must use List<> parameters. The label and description annotations are especially important as they guide the LLM in selecting and parameterising the action. (3) Prompt Template Actions: Invoke a configured Prompt Template to generate text — summarising a record, drafting an email, or classifying sentiment. (4) Knowledge Retrieval Actions: Query the Salesforce Knowledge Base to surface relevant articles, using Einstein Search with semantic ranking. Choosing the right action type balances maintainability (Flows), power (Apex), AI text generation (Prompt Templates), and information retrieval (Knowledge).

Prompt Templates are managed, versioned, and testable LLM prompt configurations stored in Salesforce. They separate prompt engineering from code and allow admins and developers to build reusable AI capabilities. Key types: (1) Flex Templates: Free-form templates used for agent instructions, system prompts, or custom generation tasks. They can merge dynamic data from Salesforce records via merge fields and template syntax. Used for defining the agent's persona and behavioural guidelines. (2) Grounding Templates (RAG): Designed to inject retrieved context (from vector search or Knowledge) into the prompt before sending to the LLM — the core mechanism of Retrieval-Augmented Generation. (3) Sales Email Templates: Pre-built template type for generating personalised prospect/customer emails using CRM data (opportunity details, contact name, company). (4) Field Generation Templates: Generate content for a specific record field — e.g., auto-populate a Case summary or Account description. (5) Record Summary Templates: Produce a natural language summary of a record's key data points. All templates support preview/testing within the Template Builder before deployment.

The Einstein Trust Layer is the security and governance framework that sits between Salesforce and any LLM provider. Its key protections: (1) Zero Data Retention (ZDR): Salesforce's agreements with LLM providers (including OpenAI and Anthropic) guarantee that data sent to the model is not used for training and is not retained after the response. No customer data persists outside the Salesforce trust boundary. (2) Data Masking and Anonymisation: Before sending a prompt to an external LLM, the Trust Layer scans for PII (names, emails, phone numbers, SSNs) and replaces them with anonymised tokens. The response is de-anonymised before being returned to Salesforce. (3) Toxicity Detection: Both input prompts and LLM responses are screened for harmful, offensive, or policy-violating content. Flagged content is blocked before reaching the user. (4) Audit Trail: Every LLM call — input prompt, output, model used, timestamp, and user — is logged in the Einstein Trust Layer Audit Trail, accessible to admins for compliance and investigation. (5) Grounding: The Trust Layer enforces that agents can only access Salesforce data the running user is permitted to see, via standard Salesforce sharing and FLS.

Retrieval-Augmented Generation (RAG) is an AI architecture pattern that improves LLM accuracy by retrieving relevant context from an external data store and injecting it into the prompt before generation. This grounds the LLM's response in factual, up-to-date data rather than relying solely on its training data. Data Cloud as a Vector Database: Data Cloud stores data as vector embeddings — high-dimensional numerical representations of text that capture semantic meaning. When an agent receives a user query, the query is also vectorised and a semantic search (cosine similarity lookup) finds the most contextually relevant data chunks. These chunks are injected into a Grounding Prompt Template. Key concepts: (1) Chunking: Source documents are split into smaller segments (chunks) before vectorisation to stay within context window limits and improve retrieval precision. Chunk size is a tuning parameter. (2) Grounding: The retrieved chunks form the factual basis for the LLM's response, dramatically reducing hallucination on domain-specific topics. (3) Data Cloud as Memory: Unified customer profiles and interaction history in Data Cloud can be retrieved to personalise agent responses with full customer context.

ReAct (Reasoning and Acting) is a prompting framework for LLM agents that interleaves explicit reasoning steps with action calls. The cycle is: (1) Thought: The LLM reasons about the user's request and the current state — "The user wants to cancel an order. I need the order ID first." (2) Action: The LLM selects and invokes a tool/action with parameters — calling the "Get Order Details" Flow with the order number extracted from the user's message. (3) Observation: The result of the action is returned to the LLM — the order details record data. The cycle repeats: the LLM reasons about the observation, determines the next action, and continues until the user's goal is fulfilled or the agent determines it cannot proceed. The Agentforce Planner implements ReAct internally — it is not visible to the admin, but understanding it explains why well-described Topics and Actions are essential: the LLM's Thought steps depend on clear, accurate descriptions to make correct selections. It also explains why providing the wrong action description causes the agent to invoke the wrong action in the Acting step.

Key requirements for Agentforce-compatible @InvocableMethod: (1) List parameters: The method must accept a single List<YourRequestClass> parameter and return List<YourResponseClass> (or List<String> for simple outputs). This is a hard Salesforce platform requirement. (2) label annotation: @InvocableMethod(label='Get Account Details') — this is what appears in Agent Builder as the action name. Make it clear and action-oriented. (3) description annotation: description='Retrieves the account name, ARR, and primary contact for a given Account ID.' — this description is passed to the LLM Planner and is critical for correct action selection. Be specific about inputs and outputs. (4) @InvocableVariable: Each field in the request/response inner classes should be annotated with @InvocableVariable(label='...' description='...' required=true/false). The description helps the LLM correctly populate the input variable from the conversation context. (5) Bulkification: Although agents typically call with one record at a time, always handle the list correctly in case of bulk invocation via other callers.

To use a Flow as an Agentforce Action: (1) Flow type: Must be an Auto-launched Flow (not a Screen Flow). The agent invokes it programmatically without user interaction. (2) Input variables: Define input variables with "Available for input" checked. The variable label and description are surfaced to the LLM — write them in natural language describing what data to pass. (3) Output variables: Define output variables with "Available for output" checked. The agent uses these values in its response or subsequent reasoning steps. Keep outputs focused — return exactly what the agent needs, not the entire record. (4) Error handling: Add Fault paths to all data operations (Get Records, Create Records, etc.) and set an error output variable so the agent can communicate a failure gracefully rather than silently stopping. (5) API Name: The API name of the Flow appears in Agent Builder when you add it as an action — use a clear, descriptive name. (6) Testing: Test the Flow independently in Flow Builder's debug mode before testing it as an agent action to isolate issues. Flows are the most admin-maintainable action type and should be preferred over Apex when the logic can be expressed declaratively.

Agentforce integrates with Salesforce Knowledge through Einstein Search for Agents. Configuration: (1) Enable Einstein Search: Ensure Einstein Search is enabled in the org and Knowledge is set up with published articles. (2) Knowledge Retrieval Action: Add a Knowledge action to the relevant Topic in Agent Builder. Specify which Knowledge article types and data categories are in scope. (3) Semantic ranking: Einstein Search uses vector-based semantic search (not just keyword matching) to surface articles whose meaning matches the user's query, even without exact keyword overlap. (4) Article ranking signals: Articles are ranked by semantic relevance, view count, and rating. Ensure articles are well-written, up-to-date, and tagged with accurate data categories for optimal retrieval. (5) Grounding: Retrieved article content is injected into the agent's context window as grounding — the agent cites and summarises article content rather than hallucinating answers. (6) Escalation: Configure the agent to escalate to a human when no relevant article is found or when confidence is below a threshold, preventing unhelpful generic responses.

Multi-agent orchestration is an architecture where a primary agent (the orchestrator) decomposes a complex goal into subtasks and delegates them to specialised worker agents, rather than one agent handling everything. (1) Orchestrator Agent: Receives the high-level user request, reasons about how to decompose it, and routes subtasks to appropriate worker agents. It synthesises the results from workers into a final response. It is responsible for the overall goal completion and managing the interaction state across agent handoffs. (2) Worker Agent: A specialised agent with a narrowly scoped set of Topics and Actions — e.g., a dedicated "Billing Agent" or "Inventory Agent". It receives a specific delegated task, executes it, and returns a result to the orchestrator. Worker agents have limited scope by design, making them easier to test, maintain, and reuse across multiple orchestrator agents. Handoff: The mechanism by which control (and relevant context) is passed from one agent to another. Context passing must be explicitly designed — workers need sufficient context from the orchestrator to complete their task without asking the user to repeat information.

Agent Builder provides a built-in test conversation panel for testing agents before deployment. Testing approach: (1) Test conversations: Enter real user messages and observe the agent's full reasoning trace — which Topic was classified, which Action was invoked, what parameters were passed, and what response was generated. (2) Expected Topic validation: Verify that each test utterance maps to the intended Topic. If the wrong topic is selected, revise the topic description or scope to reduce ambiguity. (3) Expected Action validation: Verify that within the correct topic, the correct action is invoked with correctly extracted parameters. If parameters are wrong, improve the action's description or input variable descriptions. (4) Edge cases: Test ambiguous, out-of-scope, and adversarial inputs to verify the agent handles them gracefully — either routing to a fallback, asking clarifying questions, or escalating. (5) Action output handling: Verify the agent correctly uses action output in its response — not ignoring results or misinterpreting them. (6) End-to-end data accuracy: Confirm that data retrieved from Flows or Apex matches expectations — test with real sandbox records.

Guardrails are constraints that define what an agent can and cannot do, preventing unintended or harmful behaviour. (1) Topic boundary enforcement: Topics explicitly define scope — the Planner is instructed not to fulfil requests outside any defined topic. If a user asks about something outside all topic scopes, the agent responds that it cannot help with that request and optionally suggests escalation. Tight, well-scoped topic descriptions are the primary guardrail against scope creep. (2) Action permission checking: Each action runs in the context of the running user's Salesforce permissions. A Flow or Apex action cannot access or modify records the user doesn't have permission to — standard Salesforce sharing, FLS, and CRUD enforcement applies. The agent cannot bypass Salesforce security. (3) Einstein Trust Layer toxicity detection: Filters harmful inputs before they reach the LLM and harmful outputs before they reach the user. (4) Prompt injection protection: The Trust Layer and topic architecture provide defence against prompt injection attacks where users attempt to override agent instructions through crafted inputs. (5) Escalation thresholds: Configure the agent to always escalate for sensitive operations (e.g., processing refunds above a threshold, changing account ownership) regardless of the LLM's confidence.

Agentforce agent configurations are metadata and can be deployed via: (1) Change Sets: Include the Agent Definition metadata type along with all dependent metadata — Topics, Actions, referenced Flows, Prompt Templates, and Apex classes. Validate the change set before deploying to catch missing dependencies. (2) Unlocked Packages: The recommended approach for teams using source-driven development. Package the agent metadata and its dependencies together for version-controlled, repeatable deployment. Unlocked packages support scratch org development for Agentforce. (3) Salesforce CLI / sf deploy: Deploy metadata directly from a source repository using sf project deploy start. Requires retrieving the agent metadata from the source org first with sf project retrieve start. (4) Scratch Org Support: Agentforce is supported in scratch orgs, enabling full CI/CD pipelines where agents are built in scratch orgs, unit tested, and packaged for deployment. Key considerations: Prompt Template versions must be activated in each target org; ensure LLM provider connections and model settings are configured in the target org; test agent behaviour post-deployment as LLM responses can vary across environments.

Einstein Copilot (now part of the Agentforce platform) and Agentforce represent different deployment patterns: (1) Einstein Copilot: An AI assistant embedded in the Salesforce UI sidebar — primarily user-initiated, conversational, and designed to assist a human user with tasks in context (summarise this record, draft this email, find related data). It operates within the user's current CRM context and is always supervised by the user. (2) Agentforce Agents: Autonomous agents that can operate with minimal or no human supervision — they can complete multi-step tasks end-to-end (e.g., handle a customer service case from intake to resolution, qualify a lead and create a follow-up task). They are deployed as independent agents in channels like Experience Cloud, Slack, or messaging platforms. (3) Architecture overlap: Both use the same underlying infrastructure — Topics, Actions, Prompt Templates, Einstein Trust Layer. Copilot can be thought of as a user-assistant agent; Agentforce agents are autonomous task-completion agents. The Agentforce platform unifies both under one framework in Salesforce's current product direction.

Agentforce provides flexible LLM selection: (1) Default Einstein LLM: Salesforce's hosted, pre-configured LLM (powered by partnerships with providers like Anthropic and OpenAI) available out of the box. It is the simplest option — no configuration required, and all Einstein Trust Layer protections apply automatically. (2) BYOM (Bring Your Own Model) via Model Builder: Organisations can connect external LLMs (e.g., their own fine-tuned model hosted on AWS, Azure, or GCP) through the Model Builder configuration in Setup. This allows use of proprietary models, domain-specific fine-tuned models, or models required for data sovereignty reasons. (3) Model Builder: The configuration surface in Salesforce Setup where custom model connections are defined — specifying the endpoint URL, authentication credentials, and request/response schema mapping to Salesforce's standard LLM interface. Once configured, a custom model can be selected at the Prompt Template or Agent level. (4) Model selection per template: Different Prompt Templates can use different models — e.g., a summarisation template might use a lighter model for cost efficiency while a complex reasoning task uses a larger model.

LLMs have a finite context window — the total amount of text (input + output) they can process in a single call. For agents handling long conversations or needing broad customer history, the context window is a critical constraint. Data Cloud addresses this as an agent memory layer: (1) Unified Customer Profile as Context: Data Cloud's identity resolution unifies customer data from multiple sources into a single profile. Relevant profile attributes (purchase history, service history, preferences, lifetime value) can be retrieved and injected into the agent's context at conversation start, providing personalisation without retrieving full raw records. (2) Vector Database for Semantic Memory: Conversation history and interaction data stored in Data Cloud as vector embeddings enables semantic retrieval of relevant past interactions — "the last time this customer called about billing" — without loading the entire history into the context window. (3) Context Window Management: By retrieving only the most semantically relevant chunks (via RAG) rather than all available data, the agent stays within context limits while still being well-grounded. (4) Persistent Memory: Unlike in-session agent memory which resets between conversations, Data Cloud can store and retrieve information across sessions — enabling agents to remember customer preferences and past resolutions.

Agentforce provides several layers of analytics and monitoring: (1) Conversation Logs: Every agent conversation is logged, including the full message transcript, topics classified, actions invoked, action parameters, action outputs, and final responses. Accessible in Setup under Agentforce Agent Analytics. Logs are essential for debugging and quality review. (2) Topic Classification Accuracy: Metrics showing how often each topic was classified, including instances where no topic matched (fallback rate). High fallback rates indicate topic descriptions need refinement or new topics are needed. (3) Action Success Rate: For each action, the percentage of invocations that completed successfully vs failed. Low success rates indicate Flow or Apex errors that need investigation. (4) Resolution Rate: The percentage of conversations where the agent fully resolved the user's request without escalating to a human. This is the primary operational KPI for autonomous agents. (5) Escalation Rate and Reasons: Tracks how often and why the agent escalates — by topic, by action failure, or by user request. (6) Einstein Trust Layer Audit Trail: Provides a compliance-focused log of every LLM call, data masking operation, and toxicity detection event for security and regulatory reporting.

Agentforce uses a consumption-based licensing model centred on Agent Conversations: (1) Agentforce Conversation licence: Billed per conversation (a conversation being a complete user-agent interaction session). Pricing is approximately $2 per conversation as a baseline, though enterprise contracts negotiate volume discounts. This applies to external-facing agents (e.g., on Experience Cloud or messaging channels). (2) Agentforce for Employees: Internal agents assisting Salesforce users (Sales Reps, Service Agents) — may be covered under a platform seat licence depending on the edition and contract. (3) Einstein Platform Add-on: Organisations needing higher volumes of Einstein LLM calls (for Prompt Templates, Copilot, and agent grounding) may require additional Einstein credits. (4) Data Cloud licence requirement: Certain RAG and vector database capabilities require a Data Cloud licence. Basic Knowledge integration does not. (5) Model Builder BYOM: Using a custom model via BYOM does not incur Salesforce LLM consumption costs but requires the customer to manage their own model hosting costs. Licensing should be validated against the current Salesforce price book as it evolves rapidly with the platform.

While Agentforce provides a default chat UI component that can be embedded on Experience Cloud sites and the Salesforce app, LWC enables custom agent interfaces: (1) agentforce-chat LWC: Salesforce provides a standard embedded chat component configurable via attributes — bot name, welcome message, and branding. Deployed to Experience Cloud pages or Salesforce sites with no custom code required. (2) Custom chat UI via LWC: For bespoke requirements, developers can build a fully custom chat interface using LWC and communicate with the Agentforce API (Messaging for In-App and Web API). This allows complete control over the visual design — including custom avatars, rich media cards, quick reply buttons, and carousel components that standard chat does not support. (3) Embedded in Record Pages: An LWC component on a Lightning Record Page can launch an agent conversation in context — passing the current record ID and object type as initial parameters so the agent is pre-grounded with the record's data. (4) Streaming responses: Custom LWCs can implement token streaming (displaying the agent's response word by word as it generates) for a more responsive user experience — requires consuming the streaming API endpoint.

Deploying Agentforce agents in Slack requires specific design considerations: (1) Slack channel context: Agents in Slack can be invoked via direct message or @mentioned in channels. Design Topics with awareness that channel messages may be less formal and more context-dependent than structured CRM inputs. (2) Slack Block Kit formatting: Agent responses in Slack are rendered as Block Kit messages — plain text, but with support for buttons (Quick Replies), section blocks, and dividers. Design action outputs to return structured data that maps to useful Slack card layouts. (3) Authentication: Users interacting with the agent in Slack are authenticated via Salesforce-Slack OAuth integration. Ensure the Slack user identity is correctly mapped to a Salesforce user for permission enforcement. (4) Conversation threading: Slack conversations happen in threads — ensure the agent maintains context within a thread and does not lose state between messages. (5) Action scope in Slack: Limit agent actions in public channels to read-only or low-risk operations. Sensitive operations (creating records, updating data) are better suited to direct messages where the interaction is private. (6) Notification vs conversation: Distinguish between agent-initiated notifications (proactive alerts via Slack) and reactive conversations — each requires different Flow and API designs.

The Agentforce Planner uses several strategies for ambiguous or multi-topic requests: (1) Clarifying questions: If the user's intent cannot be confidently classified, the Planner generates a clarifying question using the ReAct Thought step — "Are you asking about billing for your current subscription or a new purchase?" rather than making an incorrect assumption. (2) Confidence thresholding: The Planner assigns a confidence score to topic classification. Below a configured threshold, it defaults to asking for clarification or escalating rather than guessing. (3) Sequential multi-topic handling: If a request clearly spans two topics (e.g., "update my address and check my order status"), the Planner can execute them sequentially — completing the first topic's actions before moving to the second. (4) Topic scope specificity: The primary defence against misclassification is well-written, non-overlapping topic descriptions with explicit scope boundaries. Topic descriptions should include representative example phrases to anchor the LLM's classification. (5) Fallback topic: Configure a fallback/default topic with a catch-all scope that escalates to a human agent when no other topic matches — preventing the agent from attempting to answer out-of-scope requests.

(1) Agent Instructions (System Prompt): Configured directly in Agent Builder as the agent's role definition and behavioural guidelines — e.g., "You are Aria, a friendly customer service agent for Acme Corp. Always respond in a professional tone. Never discuss competitor products. If unsure, escalate." These instructions are prepended to every LLM call as the system prompt and define the agent's persona, constraints, and general behaviour across all Topics. They are managed in Agent Builder's "Instructions" panel. (2) Prompt Templates: Reusable, versioned templates for specific generation tasks — record summarisation, email drafting, RAG grounding. They are invoked as discrete Actions within a topic, and can merge dynamic Salesforce data via template merge syntax. They have their own test/preview tooling, version history, and can be reused across multiple agents and topics. (3) Relationship: The system instructions set the agent's overall behaviour context; Prompt Templates generate specific content for specific tasks. A template executes within the context established by the system instructions — the agent's persona applies to template-generated responses. Both are separate metadata types managed independently, enabling the agent's persona to be updated without touching templates, and templates to be reused across different agents with different personas.

Common failure modes and diagnostic approaches: (1) Wrong topic classification: Symptom — agent invokes the wrong set of actions or gives irrelevant responses. Diagnosis — review the conversation log's topic classification trace. Fix — rewrite topic descriptions to be more specific and add explicit exclusions for commonly confused intents. (2) Action invoked with wrong parameters: Symptom — Flow or Apex receives null or incorrect input values. Diagnosis — examine action input values in the conversation trace. Fix — improve @InvocableVariable or Flow variable descriptions so the LLM correctly maps conversation context to parameters. (3) Action failure / Fault path triggered: Symptom — agent reports it cannot complete the request. Diagnosis — check Flow debug logs or Apex debug logs for the error. Fix — add better error handling and return meaningful error messages via output variables. (4) Hallucinated responses: Symptom — agent provides plausible but incorrect information. Diagnosis — check if the relevant Action was actually invoked; if not, the agent generated the response from training data. Fix — ensure a Knowledge or data retrieval action exists for the relevant topic and that grounding is correctly configured. (5) Scope creep / out-of-topic responses: Symptom — agent responds to requests it should escalate. Fix — tighten topic scope descriptions and ensure a fallback escalation topic is configured.

Prompt Template governance is critical because changes to a template directly affect agent behaviour and quality. Best practices: (1) Versioning: Salesforce stores Prompt Template versions natively — each save creates a new version. Only one version is active at a time. Review version history to understand how a template evolved and roll back if a change degrades output quality. (2) Source control: Retrieve template metadata using Salesforce CLI and store it in a Git repository. This enables peer review of prompt changes via pull requests, the same as code changes. (3) Test cases: Maintain a documented set of representative inputs and expected outputs for each template. Run these test cases against new template versions in a sandbox before promoting to production. (4) Staging environment testing: Always test prompt changes in a sandbox or scratch org with real representative data before deploying. LLM outputs are non-deterministic — test multiple times with the same input to assess consistency. (5) Separation of concerns: Keep templates focused on a single responsibility. A template that both retrieves data and formats an email response is harder to maintain than two templates with clear boundaries. (6) Documentation: Add inline comments in the template (where the template engine supports it) describing the intent, expected inputs, and the grounding data source — making templates self-documenting for the next maintainer.