Top 30 Salesforce Agentforce Interview Questions and Answers (2026)

Strong answer

Agentforce is the agent-driven layer of the Salesforce Platform for building and deploying AI agents that assist employees or serve customers. An agent can interpret a request, choose an appropriate subagent and actions, retrieve approved context, execute Salesforce business logic, and respond through connected channels.

I would not describe Agentforce as only a chatbot or an LLM wrapper. Its value comes from combining conversational reasoning with Salesforce data, identity, permissions, Flow, Apex, Prompt Builder, Data 360, APIs, and operational tooling. A production design must therefore cover both AI quality and ordinary enterprise concerns such as authorization, transactions, retries, monitoring, and human escalation.

Salesforce’s Agentforce Developer Guide describes it as the agent-driven layer of the platform and maps the APIs, SDKs, actions, Agent Script, and DX tools used to extend it.

Strong answer

A traditional rules-based bot usually follows predefined intents and dialog paths. Flow and Apex execute explicitly modeled logic. Agentforce can interpret varied natural-language requests, reason over the available capabilities, select actions, and maintain a multi-turn conversation.

That does not make Flow or Apex obsolete. They remain strong action implementations for deterministic work. I use Agentforce for language understanding, orchestration, clarification, and response generation; I use Flow or Apex for governed calculations, validation, record updates, integration logic, and other behavior that must be consistent.

The architecture is strongest when every layer has a clear job. If a refund rule must always reject an ineligible order, that rule belongs in deterministic business logic—not only in a sentence asking the LLM to remember the policy.

Strong answer

I explain the building blocks as a system:

• Subagents, previously called topics, divide the agent into coherent areas of responsibility.
• Instructions guide reasoning, clarification, sequencing, tone, and response behavior.
• Actions retrieve information or perform work through standard capabilities, Flow, Apex, prompt templates, APIs, and other supported implementations.
• Variables and context carry explicit state and make capabilities available only when conditions are satisfied.
• Grounding data gives the agent approved business knowledge and record context.
• Connections and channels determine where the agent is available and how it escalates or hands work to other systems or people.
• Tests, versions, traces, and analytics make the agent governable through its lifecycle.

An interview answer should show how these pieces interact rather than list them as isolated definitions.

Strong answer

In current Salesforce terminology, topics are being renamed subagents. Salesforce states that the name change began in April 2026 and does not change the underlying functionality. A subagent still groups a specialized responsibility, its instructions, actions, variables, and routing behavior.

In an interview, I would acknowledge both names because the org, release, certification material, and documentation may not all use the new label yet. Then I would focus on design: subagents need distinct responsibilities and clear boundaries. “Orders,” “Returns,” and “Account Access” are easier to route and test than several overlapping subagents that can all answer a generic support request.

The current terminology note appears in Salesforce’s Agentforce APIs and SDKs overview.

Strong answer

Atlas is the reasoning layer that interprets the conversation and available context, chooses the relevant subagent, determines which actions may help, evaluates action results, and forms the response. The exact workflow can involve multiple prompts, model calls, code, action execution, and repeated reasoning steps.

The practical implication is that names, descriptions, scopes, instructions, input descriptions, and action outputs all influence behavior. If the wrong action runs, I do not immediately blame the model. I inspect classification boundaries, action descriptions, availability filters, variable initialization, permissions, and the data returned by the action.

Salesforce’s Atlas Reasoning Engine workflow explains the progression from invocation and classification through context injection, action execution, and response generation.

Strong answer

The classification description helps the reasoning engine decide whether the user’s request belongs to a subagent. The scope defines what that subagent can and cannot handle after it is selected. Instructions guide how it should reason, clarify, sequence actions, format the response, and handle exceptions.

I keep each layer focused. Classification should use the language users actually use and distinguish neighboring subagents. Scope should state a clear boundary. Instructions should be concise, testable, and ordered around the task—not a dumping ground for every company policy.

If two subagents classify the same utterances, rewriting response tone will not fix routing. If the right subagent is selected but the wrong action runs, I inspect action names, descriptions, inputs, filters, and sequencing instead.

Strong answer

Natural-language instructions are useful for conversation flow, clarification, tone, response structure, and helping the agent choose among safe actions. They are interpreted by an LLM, so their outcome can vary.

Authorization, eligibility, financial calculations, regulatory controls, irreversible updates, uniqueness, and other business invariants belong in deterministic logic such as the action implementation, Flow, Apex, validation rules, or Agent Script conditions. The action must reject an unauthorized refund even if a prompt injection tells the agent to ignore policy.

My rule is simple: if the organization must prove that a rule always executes, I do not rely on a natural-language instruction as the only enforcement point. Salesforce gives similar guidance in Prompt Fine-Tuning in Agentforce.

Strong answer

Agent Script is the language used in the new Agentforce Builder to combine natural-language reasoning with programmatic control. It supports variables, conditions, action chaining, subagent transitions, and explicit places where the LLM may reason.

I use it when an agent needs a predictable route or stateful workflow that would be fragile as prompt text alone. For example, verify a customer, store the verified state, make the Returns subagent available only after verification, run an eligibility action, and escalate when the action returns a governed exception.

I still keep domain logic inside actions where it can be reused and tested. Agent Script orchestrates; it should not become a second copy of every calculation. See Get Started with Agent Script.

Strong answer

Variables store explicit session state, action outputs, or values needed by conditions and later actions. Context variables carry approved channel or session context into the agent. Filters and availability conditions use that state to control which subagents or actions are eligible.

I initialize variables deliberately, give them meaningful names, and map them from trusted sources. I do not assume that an LLM will infer a security-critical value from conversation text. For example, verified_customer_id should come from a verification action or trusted channel mapping, not from a user saying “I am customer 123.”

Variables improve determinism, but they are not automatically authorization. The action and Salesforce access model must still verify the operation. Salesforce’s variables pattern covers state, action-output mapping, and availability conditions.

Strong answer

I reduce ambiguity before adding more instructions. Subagents need distinct classification descriptions and scopes. Actions need unique names, precise descriptions, clear input instructions, and availability filters. I remove duplicate tools that appear to do the same thing and expose only the minimum actions required for the current state.

Where routing must be guaranteed, I use Agent Script conditions or deterministic transitions. Where the LLM can choose safely, I provide representative phrases and test the boundary between similar intents.

Then I use traces to see whether failure occurred during classification, action selection, input construction, action execution, or response generation. The repair must target the failing layer; adding a global prompt paragraph often hides the symptom without fixing the cause.

Strong answer

Grounding supplies relevant enterprise context to the model so the response is based on approved Salesforce records, knowledge, documents, or other connected sources instead of only the model’s general training.

Grounding improves relevance but does not guarantee truth. Retrieval can return the wrong passage, stale content, conflicting policies, or no useful evidence. I define which sources are authoritative, apply access controls, tune retrieval, require citations where the experience supports them, and give the agent a safe “not enough information” behavior.

I also separate retrieval from action data. A policy document can explain return rules, while a deterministic action checks the actual order and eligibility. The model should not infer transaction eligibility from a paragraph when the source system can calculate it.

Strong answer

An Agentforce Data Library connects an agent to trusted unstructured or semi-structured information. Salesforce automates supporting configuration across Data 360 and Prompt Builder, including data ingestion, mapping, search indexing, and a retriever.

I still treat content preparation as an architecture task. Long, duplicated, outdated, or poorly structured documents produce weak retrieval. I assign content owners, remove obsolete versions, define access, choose useful chunk boundaries, test representative questions, and measure whether the retrieved passages actually support the answer.

Each library has its own retriever, so I confirm that the agent is connected to the intended library and that ingestion and indexing completed. Salesforce explains these mechanics in What Are Data Libraries?.

Strong answer

I use structured data and actions when the answer depends on exact records, current values, relationships, permissions, or calculations: order status, account balance, entitlement, appointment availability, or case ownership.

I use retrieval over a Data Library for explanatory content such as product manuals, policies, troubleshooting articles, or contractual guidance. Many useful agents combine both. A service agent retrieves the warranty policy, then invokes a governed action to check the customer’s product, purchase date, and eligibility.

The interview trade-off is precision versus flexibility. Semantic retrieval is good at finding relevant language; a deterministic record query or action is better at enforcing a current transactional truth. I do not use an unstructured document as the source of truth for a value already maintained in Salesforce.

Strong answer

I reduce the opportunity to invent. I narrow each subagent’s scope, expose fewer and clearer actions, ground responses in approved sources, request citations where applicable, and encode critical decisions in deterministic actions. Instructions tell the agent to distinguish confirmed facts from assumptions and to say when evidence is missing or conflicting.

I test retrieval quality separately from response quality. If the correct passage never reaches the model, rewriting the final-response prompt is unlikely to solve the problem. I also preserve action outputs and trace evidence so support can identify whether the failure was routing, retrieval, action data, or generation.

Finally, I define human review or escalation for high-impact outcomes. Hallucination risk is not only an accuracy percentage; it is the business consequence of a wrong answer or action.

Strong answer

I describe the Trust Layer as a set of security and privacy controls around model interactions, combined with Salesforce identity, permissions, field-level security, and sharing. Salesforce also documents zero-data-retention arrangements for data sent to external model providers and audit capabilities for supported generative AI activity.

I avoid making a blanket claim that every Agentforce prompt is masked. Salesforce currently documents that pattern- and field-based LLM data masking is disabled for agents because masking can remove context required for reasoning. That makes least-privilege data access, action design, source selection, logging policy, and data classification even more important.

The exact model hosting, regional, retention, and product settings must be verified for the org. See Trust and Agentforce and Data Masking Limitations in Agentforce.

Strong answer

A customer-facing Service agent can run as a dedicated agent user when it cannot rely on a logged-in end user’s Salesforce identity. That user record, profile, permission sets, field permissions, and sharing determine what the agent can read and change.

I start from the secure minimal baseline and grant only the objects, fields, records, Apex classes, Flows, prompt templates, and integration capabilities required by approved actions. I test both access and non-access with real personas. Giving the agent broad internal access because “customers still have to ask for the record” is unsafe—the conversation is not an authorization boundary.

The design differs when an authenticated channel runs in a user’s context, so I document the running identity for every channel. Salesforce provides the detailed model in Configure Service Agent Access.

Strong answer

No. A context variable can identify or route conversation context, but it does not replace Salesforce authorization. A user-provided account number or contact ID must not become trusted merely because it was stored in a variable.

I derive security-sensitive variables from a verified channel mapping or identity action, and the underlying action queries only records the running identity is allowed to access. For write actions, I recheck ownership, relationship, permission, and business eligibility inside deterministic logic.

This distinction prevents insecure direct-object-reference patterns. The agent can know which customer the conversation appears to concern while still being forbidden to read or update that customer’s data until verification and Salesforce access both succeed.

Strong answer

I treat the action as an API boundary. It validates structured inputs, enforces object, field, and record access as required by the execution model, applies deterministic business rules, rejects out-of-scope records, and returns a safe error without leaking internals.

For high-impact work, I separate proposal from commit: show the user exactly what will change, obtain explicit confirmation, then execute with an idempotency key and audit record. I limit the action’s output to what the conversation needs and avoid returning sensitive fields just because the running user can query them.

I also test replay, concurrent requests, stale state, partial failure, and malicious inputs. Prompt instructions can guide when to call the action; the action itself must remain safe even when called with unexpected values.

Strong answer

I assume user text, documents, websites, emails, and action outputs can contain adversarial instructions. Retrieved content is evidence, not a new system policy. It must not be able to expand tool access, change authorization, or override deterministic controls.

I minimize available actions, filter them by verified state, validate every action input, keep secrets out of prompts, and enforce policy inside the action. Instructions tell the agent to ignore commands embedded in source material and to escalate suspicious or unsupported requests, but those instructions are defense in depth—not the only control.

Testing includes direct and indirect prompt injection, encoded instructions, requests for hidden prompts or data, cross-customer record attempts, and multi-turn manipulation. I monitor guardrail and trace signals and maintain an incident process for harmful behavior.

Strong answer

The available action mechanisms evolve, so I start with the current developer guide and the org’s release. Common options include Flow-based actions, prompt-template actions, Apex invocable methods, Apex REST, Aura-enabled Apex, named-query actions, and standard Salesforce actions.

I choose the implementation from the workload. Flow is good for transparent low-to-moderate complexity orchestration. Apex is better for complex collection logic, reusable domain services, transaction control, or advanced integration behavior. Prompt templates are appropriate for generation or transformation grounded in approved inputs, not for enforcing critical business rules.

Every action needs a unique name, precise description, explicit inputs and outputs, security behavior, failure contract, and tests. The current catalog is documented in Agentforce Actions.

Strong answer

I use Flow for maintainable process orchestration and ordinary Salesforce record work that declarative builders can support. I use Apex when the action needs complex algorithms, efficient Sets and Maps, sophisticated error recovery, reusable services, high-volume processing, or a precise security and transaction model.

I use a prompt template when the task is genuinely generative: summarize approved evidence, classify text, draft a response, or extract a structured interpretation. I keep the prompt inputs narrow and validate any generated output before using it in a transaction.

A hybrid is common. The action implementation gathers authorized data and enforces eligibility, a prompt template drafts human-readable content, and Flow or Apex records the reviewed outcome. The boundary should be easy to test and support.

Strong answer

I design write actions as idempotent operations. The caller supplies or the system derives a stable request key. The action checks for an existing successful or in-progress operation before creating another side effect, and it returns the prior result when repeating the same request is safe.

For external calls, I persist request, response status, attempt count, correlation ID, and reconciliation state. A timeout is an unknown outcome, not proof of failure; blindly retrying can create two refunds, orders, or appointments. The external contract should accept an idempotency key or expose a status lookup.

The conversational response must match the transaction evidence. If completion is unknown, the agent should say the request is being checked—not confidently report success.

Strong answer

Escalation is a product path, not a generic fallback sentence. I define when the user can request a person, which risk or failure conditions force transfer, the target queue, operating hours, capacity behavior, and what happens when no representative is available.

The handoff should include the verified identity, concise issue summary, actions already attempted, relevant record links, and conversation history allowed by policy. It must not claim that a transfer occurred until routing confirms it.

Agentforce supports escalation subagents and Agent Script escalation utilities for supported service and employee-agent channels, typically connected to Omni-Channel routing. Channel behavior varies, so I test the actual destination and unavailable path. See Transfer Conversations with an Omni-Channel Flow.

Strong answer

I create a test matrix across layers:

• routing to the expected subagent;
• expected action sequence and input mapping;
• deterministic action outcomes and failure behavior;
• grounded-answer faithfulness, completeness, and citations;
• multi-turn clarification and state;
• authorized and unauthorized personas;
• prompt injection, harmful input, and unsupported requests;
• duplicate, retry, timeout, and concurrency behavior;
• escalation and channel behavior;
• latency, consumption, and business outcome.

I use fixed regression utterances, paraphrases, ambiguous requests, and adversarial cases. Because agent responses can vary, I test invariants and acceptable ranges rather than requiring every answer to match one exact paragraph. Test data must be safe and isolated because agent tests can execute actions and change records.

Strong answer

Testing Center is the UI-oriented option for generating or importing test cases and reviewing results at scale. Agentforce DX brings agent tests into source control and CI/CD with command-line workflows and YAML specifications. The Testing API supports programmatic test definitions and execution through Metadata API and Connect API, including custom evaluation criteria.

I choose based on the team and governance model, and I often combine them: business experts explore cases in Testing Center, developers version regression suites with Agentforce DX, and pipelines use automated gates.

Salesforce currently documents agent testing as sandbox-only and warns that tests consume requests or credits and can modify data. I therefore use dedicated users, bounded fixtures, cleanup, and explicit write-action controls. See Get Started with Testing Agents.

Strong answer

I separate deterministic expectations from quality evaluations. Routing, action sequence, authorization, records changed, and escalation state can have exact expectations. Generated language is better evaluated for grounded facts, required content, prohibited content, completeness, coherence, conciseness, and latency.

I run important cases more than once and track distributions, not a single lucky result. I version the agent, test set, data fixture, model configuration where visible, and evaluation thresholds so regressions can be reproduced.

LLM-as-a-judge metrics can help triage large sets, but I calibrate them against human-reviewed examples and keep human review for high-risk outcomes. Salesforce’s AiEvaluationDefinition supports expected subagents, action sequences, string or numeric checks, and response-quality metrics in the Testing API metadata model.

Strong answer

I locate the first incorrect step instead of rewriting everything. Did the request route to the wrong subagent? Was the right action unavailable? Were inputs missing or incorrectly mapped? Did the action run under insufficient permissions? Did retrieval return irrelevant text? Was the action output correct but the final response misrepresented it?

I reproduce the utterance in Builder preview or a test, inspect the action sequence, variables, filters, retrieval, errors, latency, and final generation, then change the smallest responsible layer. I add the failure to the regression set before releasing the fix.

If behavior differs by channel or user, I compare running identity, context-variable mapping, licenses, permissions, data, agent version, and channel configuration. “It works for the admin in preview” is not production evidence.

Strong answer

I develop and test in a sandbox or appropriate scratch org, keep agent source and related metadata in version control, validate the target environment, deploy dependencies, run the regression suite, and activate the approved version deliberately.

Agentforce Builder supports drafts and committed versions; committed versions are not edited in place. Agentforce DX provides pro-code creation, preview, test, retrieval, deployment, activation, and deactivation workflows. Agent metadata has also changed across API versions, so both source and target org release compatibility matter.

I include custom objects, fields, permission sets, Flows, Apex, prompt templates, Data 360 dependencies, channel setup, credentials, and manual configuration in the release runbook. See Agentforce DX and Agentforce metadata types.

Strong answer

I monitor technical and business outcomes: session volume, successful task completion, escalation and abandonment, user feedback, wrong-subagent patterns, action errors, retrieval quality, response faithfulness, latency, safety signals, and consumption. For write actions I reconcile Salesforce and external-system results.

Session traces help identify where time or failure occurred across routing, retrieval, variables, actions, and response generation. Aggregate trends show whether one subagent, action, document set, channel, or user segment needs attention.

I define alert thresholds, owners, triage playbooks, privacy controls for stored conversation data, and an emergency deactivation or feature-control path. Salesforce’s Agentforce Observability tools describe analytics, optimization, tracing, health monitoring, and guardrail monitoring capabilities.

Strong answer

I would separate Order Status, Returns, Refunds, General Policy, and Escalation into clear subagents. A verified channel mapping or identity action establishes the customer context. Availability filters keep return and refund tools hidden until verification succeeds.

Structured actions retrieve orders and calculate eligibility. A Data Library grounds policy explanations. Refund approval and amounts remain deterministic. The agent summarizes the proposed change and asks for confirmation before a write action. Each mutation uses an idempotency key and durable status; unknown external outcomes go to reconciliation rather than an automatic duplicate retry.

I apply least privilege to the agent user, restrict fields and records, test cross-customer attempts and prompt injection, and configure Omni-Channel escalation. The regression suite covers routing, paraphrases, missing order numbers, ineligible returns, duplicate requests, action failures, multi-turn context, unauthorized users, and human transfer. After launch I monitor resolution, escalation, errors, latency, retrieval quality, refund reconciliation, and customer feedback.

That answer demonstrates the complete lifecycle: conversation design, deterministic business control, security, reliability, testing, and operations—not only prompt writing.