Agentforce Service Agent is Salesforce's bet on autonomous AI for customer service — an agent that decides what to do based on the conversation rather than following a pre-built decision tree. This guide covers what it actually does, the prerequisites you need before turning it on, how to structure topics and actions, and the guardrails that prevent the agent from going off the rails.
What is the Agentforce Service Agent?
The Service Agent is one of three pre-built Agentforce templates (Sales, Service, Customer Insights). It's designed for customer-facing conversations where the agent:
- Receives a message from a customer (web chat, Slack, WhatsApp, MuleSoft channel).
- Classifies into a topic — which broad area is this question about? (Order Status / Refunds / Product Info / Account Settings...)
- Picks an action — within that topic, which specific Apex / Flow / Prompt Template should run? (Look up Order, Calculate Refund, Update Address...)
- Runs the action — grounded by Data Cloud retrieval-augmented generation (RAG) so responses use your data, not generic LLM training.
- Replies in natural language — the LLM phrases the result conversationally.
- Hands off if confidence is low — escalates to human via Omni-Channel.
The architecture difference from Einstein Bots: there's no scripted dialog tree. The agent reasons about the conversation in context.
Prerequisites
Before you can build the Service Agent:
- Data Cloud — provisioned with at least one data space.
- Einstein Generative AI — turned on for your region (US, EU, APAC supported as of 2026).
- Agentforce add-on SKU — Industries clouds bundle some allotment, otherwise it's a paid add-on on top of Sales/Service Cloud Enterprise+.
- Permissions — admins setting it up need Customize Application, Data Cloud User, Use Agentforce, Execute Prompt Template. See How to enable Agentforce in Salesforce for the full step-by-step.
Step 1 — Create the agent
Setup → Einstein → Agentforce Builder → New Agent → choose Service Agent template. The template ships with starter topics ("Inquire About Order Status", "Update Account Information") that you can keep, modify, or delete. Pick a clear name and a user the agent runs as — this is the security context for every action it executes. Use a dedicated integration user with narrow profile, not a real human.
Step 2 — Define topics
Topics are how the agent categorizes incoming messages. Each topic needs:
- Name (internal label).
- Description — the prose the agent reads to decide if a message belongs here. Be specific. "Order Status — Use this when the customer asks about an existing order's progress, shipment, or delivery date" routes correctly. "Order stuff" doesn't.
- Scope — opt-in or opt-out for which conversations consider this topic.
Three to seven topics is the sweet spot. Too few and the agent picks the wrong action; too many and routing accuracy drops.
Step 3 — Attach actions
Each topic gets 1–10 actions. Three flavors:
| Action type | Use case |
|---|---|
| Apex Class | Query Salesforce, call external APIs, complex logic |
| Flow | Multi-step record updates, approval routing, declarative |
| Prompt Template | Generative response with variables (draft email, summarize case) |
Each action has a description that tells the agent when to invoke it. Like topics, the description is critical: it's how the LLM decides "this is the right action for this user message."
// Example: Apex action that looks up an order by number
@InvocableMethod(label='Get Order Status' description='Returns shipment status for a given order number')
public static List<OrderResult> getOrderStatus(List<OrderRequest> requests) {
List<OrderResult> results = new List<OrderResult>();
for (OrderRequest r : requests) {
Order__c o = [
SELECT Id, Status__c, Shipment_Date__c, Tracking_Number__c
FROM Order__c WHERE Order_Number__c = :r.orderNumber LIMIT 1
];
results.add(new OrderResult(o));
}
return results;
}
The @InvocableMethod description and the @InvocableVariable field descriptions are what the agent uses to decide which action to pick — write them like you're explaining to a junior coworker, not a compiler.
Step 4 — Test in the Plan tab
The Plan tab simulates conversations. You type messages as a customer would; Salesforce shows you which topic the agent classified it into, which action it picked, what Apex/Flow output came back, and what the final natural-language reply looks like. Iterate here until the agent picks the right topic + action ~95% of the time on representative test messages.
Step 5 — Deploy to a channel
Agentforce Service Agent connects to:
- Embedded Service chat (the standard Salesforce chat widget).
- Slack (via Slack-Salesforce integration).
- WhatsApp (via Service Cloud Voice + WhatsApp BSP).
- API — direct REST endpoint for custom apps.
Deploy starts small — internal beta or a single low-traffic page — before opening to all customers.
Limits and guardrails
Three categories to watch:
- Governor limits. Each action is regular Apex — same SOQL/DML/CPU limits apply. Bulk-safe code is non-negotiable since concurrent customer messages mean concurrent action invocations.
- Action timeout. The agent expects ≤60 seconds per action. Long operations (refund processing, third-party callouts) should be queued (Queueable Apex or Platform Events) with the agent saying "I've started that — I'll follow up in a minute" rather than blocking.
- Topic boundary. Don't let one topic do too much. "Order Management" with 30 actions confuses the agent. Split into "Order Status", "Order Cancellation", "Order Returns" — three focused topics.
Guardrails before launch
- Profanity / off-topic filtering. The Einstein Trust Layer handles obvious cases, but add a topic for "I don't know how to help with that" with a sensible response and human handoff.
- PII redaction. Trust Layer redacts SSN/credit card patterns by default. Verify in the Plan tab with synthetic data.
- Logging. Every conversation goes to AgentSession objects; review weekly for failed handoffs and topic misses.
- Escalation path. Always have a "transfer to human agent" action wired to Omni-Channel. Customers will eventually need it, and an agent that traps them on a chat is a churn driver.
When NOT to use Agentforce Service Agent
- Simple deflection — if your top 5 customer questions all have static FAQ answers, an Einstein Bot is cheaper and faster.
- Highly regulated workflows — agent-driven decisions in healthcare, finance, legal need extensive testing and may face compliance review. Start with Sales Agent or Customer Insights instead.
- Low conversation volume — under ~50 conversations/month, the per-action cost outweighs the human-agent cost.
Agentforce Service Agent isn't a chatbot upgrade — it's a different paradigm. You stop scripting dialogs and start describing capabilities, then trust the LLM to orchestrate. Done well, it handles 60-80% of common customer questions autonomously and escalates the rest with full context. Done poorly, it confidently hallucinates wrong answers and damages your brand. The discipline above is the difference.
For the foundational setup (enabling Agentforce, prerequisites, permissions), see How to Enable Agentforce in Salesforce.
Leave a Comment