Salesforce Service Cloud: The Agentforce Service Guide
Salesforce officially renamed Service Cloud to Agentforce Service. The product is the same — Cases, Knowledge, Omni-Channel, and a growing layer of AI agents — but the architecture is evolving fast. Here’s a practitioner’s tour, end to end.
What Is Salesforce Service Cloud (Now Agentforce Service)?
Salesforce Service Cloud is the post-sale customer service product in the Salesforce ecosystem. It exists alongside Sales Cloud (pre-sale), Marketing Cloud (outreach), and the industry clouds (FSC, Health Cloud, etc.). Where Sales Cloud is built around the Lead and Opportunity, Service Cloud is built around the Case — a record of one customer’s question, complaint, or issue.
As of the Spring ’26 release, Salesforce officially rebranded Service Cloud as Agentforce Service. The current help documentation describes cases as “the backbone of Agentforce Service (formerly Service Cloud).” The product itself, the objects, the APIs, and the licensing did not change — what changed is how Salesforce wants you to think about it: not as a CRM cloud with bolted-on automation, but as a platform where human service reps and AI service agents share the same case queue.
The terms “Service Cloud” and “Agentforce Service” both refer to the same product. Salesforce uses them interchangeably across current docs, marketing pages, and certification materials. Existing exams, license SKUs, and customer contracts still reference “Service Cloud.”
The four pillars of Service Cloud
Strip away the marketing and Service Cloud reduces to four functional pillars. Everything else — Voice, Messaging, Field Service, Agentforce — is built on top of these:
Salesforce sells Service Cloud across five editions — Starter Suite, Pro Suite, Enterprise, Unlimited, and Einstein 1 Service — with each higher tier unlocking more channels, more automation, and more AI. Feature availability by edition is documented in the official Supported Editions reference, which should be the source of truth for any “does my org have this?” question.
The Case Object: The Heart of Salesforce Service Cloud
The Case object is a standard Salesforce object that ships with every org — but it only becomes the center of a real support practice when Service Cloud features are turned on. Out of the box, Cases support all the things you’d expect: a Subject, Description, Status, Priority, Origin, owner, related Account, related Contact, and a feed of activities.
Where Service Cloud extends the Case is in everything around it:
Case-related objects every admin should know
| Object | Type | Purpose |
|---|---|---|
Case | Standard | The customer issue itself |
CaseComment | Standard | Internal or public notes on the case |
EmailMessage | Standard | Inbound and outbound email tied to a case |
CaseTeamMember | Standard | Users collaborating on a case (with predefined roles) |
Entitlement | Standard | SLA contract linking accounts to support level |
MilestoneType / CaseMilestone | Standard | Time-based commitments inside an entitlement |
Incident | Standard | Underlying issue affecting multiple cases |
Problem | Standard | Root cause behind one or more incidents |
Two other features are worth calling out because they catch admins off guard:
Case Hierarchies. A case can have a parent case, which is how organizations model “this complaint is the same as the one I filed last week” or “this is a sub-task of a larger investigation.” Hierarchies are independent of Incidents and don’t share severity rollups.
Case Merge. Lightning Experience supports merging up to three duplicate cases into one master record, similar to Lead and Account merge. The merge consolidates Case Comments, Emails, and most related lists onto the surviving record.
Customize Case Sharing Settings explicitly — don’t accept the default. Many orgs set Cases to Private OWD plus a Case Team-based sharing model. If you leave Cases at Public Read/Write, anything routed to a queue is visible to everyone in the org, which is rarely what executives want.
Capturing Cases from Every Channel
A customer issue only becomes a Case when it lands in Salesforce. Service Cloud supports a long list of intake channels, each with its own setup, license requirements, and routing behavior. The main ones, from oldest to newest:
Email-to-Case
Inbound emails to a designated support address (support@yourcompany.com) automatically create Case records. Two flavors exist: On-Demand Email-to-Case (cloud-only, recommended) and Email-to-Case (requires a customer-hosted Email Agent service for inbound polling — rare in modern implementations).
Web-to-Case
A generated HTML form embedded on the customer’s website posts directly to Salesforce and creates a Case. Each org gets up to 5,000 Web-to-Case submissions per day. It’s the oldest channel and still useful for low-volume B2B sites, but most modern implementations replace it with Experience Cloud forms or messaging.
Messaging for In-App and Web (MIAW)
The current generation of chat/messaging. Replaced the legacy Live Agent product. MIAW supports embedded chat on web and mobile apps, persistent conversations, file attachments, and routing through Enhanced Omni-Channel. Sessions can spawn Cases automatically through an Omni-Channel Flow.
Service Cloud Voice
Voice integrates a contact center — Amazon Connect or partner telephony — directly into Salesforce. Voice calls are routed by Omni-Channel, transcribed in real time, and the resulting VoiceCall records can spawn Cases. Conversation Intelligence analyzes the transcript for keywords and surfaces Next Best Actions to the rep.
Experience Cloud (formerly Communities)
A self-service portal where customers can view their cases, file new ones via a contact request, search Knowledge, and interact with peers. The “Help Center” template is the current recommended starting point for an Experience Cloud-based service site.
Social Customer Service
Salesforce retired the original Social Customer Service feature, but the equivalent capability lives in Digital Engagement add-ons that connect Facebook Messenger, WhatsApp, SMS, and other channels through MIAW.
The legacy Live Agent chat product is being retired. New chat implementations should use Messaging for In-App and Web (MIAW). Existing Live Agent orgs continue to function but will not receive new features.
Omni-Channel Routing: Standard vs Enhanced
Omni-Channel is the routing engine that decides which service rep — or AI agent — receives an incoming work item. It supports cases, leads, custom objects, chats, voice calls, and messaging sessions. Crucially, Salesforce maintains two generations of Omni-Channel in parallel:
Standard Omni-Channel
- Original routing engine
- Supports cases, leads, and custom objects
- Routes via Queues and Routing Configurations
- Routing rules configured in Setup UI
- Does NOT support Enhanced Bots, MIAW, Voice, or Agentforce Service Agents as destinations
Enhanced Omni-Channel
- Newer architecture using Pending Service Routing (PSR) records
- Supports all channels: cases, chats, voice, messaging, AI agents
- Routing logic built declaratively in Omni-Channel Flows
- Required for Agentforce Service Agent routing
- Required for MIAW and Service Cloud Voice
- Salesforce-recommended path for new implementations
The Service Cloud Consultant exam tests both architectures. Memorize which features require Enhanced (MIAW, Voice, Agentforce Service Agents, Enhanced Bots) and which features work in Standard (basic case and lead routing only). Upgrading from Standard to Enhanced is a one-way migration with sandbox testing recommended.
The four routing methods
Inside Omni-Channel, work can be routed using one of four configured methods. They’re not mutually exclusive — many orgs use multiple in parallel:
- Basic Routing — Routing Configuration sends all work from a queue using a single routing model (Least Active, Most Available, External Routing). Simple and fast to configure.
- Advanced Routing with Omni-Channel Flows — Routing logic built in Flow Builder using the Route Work action. Supports complex conditional routing, screen pops, and skill-based decisions.
- Skills-Based Routing Rules — Map field values on the work item (case priority, account tier, language) to required skills, and route to the rep best matched. Configured from the Routing Configuration record.
- Omni-Channel Unified Routing — A unified routing model for Voice scenarios that combines call queue and Omni-Channel queue behavior.
Routing Destinations: From Queues to AI Agents
Omni-Channel supports five distinct routing destinations. Each represents a different “what receives this work item?” answer. Knowing which destinations are supported in Standard vs Enhanced Omni-Channel is heavily tested:
| Destination | Description | Available In |
|---|---|---|
| Queue | Work goes to a queue; available members pull from it via Omni-Channel | Standard + Enhanced |
| Skill | Work routes to the rep whose assigned skills best match required skills | Standard + Enhanced |
| Support Rep | Direct routing to a specific human user (e.g., a customer’s named advisor) | Standard + Enhanced |
| Agentforce Service Agent | Routes to an AI agent that can resolve cases autonomously | Enhanced only |
| Bot | Routes to an Enhanced Bot (deflection-focused, scripted flows) | Enhanced only |
Queue-based routing is conceptually the simplest: an admin creates a Queue with a list of members, attaches a Routing Configuration that picks the routing model, and Omni-Channel does the rest. Skills-based routing is more nuanced because it depends on a complete skill matrix — every rep must have the right skills assigned, and every work item must have its required skills set, or the work falls through to a fallback queue.
An OmniRoutingConfiguration sits between the queue and the rep. It defines the capacity model (units- vs status-based), routing model (Least Active, Most Available, External Routing), and a priority. When new work hits the queue, Omni-Channel reads the configuration to decide who gets it.
Case Automation: Rules and Order of Execution
Service Cloud has three case-specific automation rule types that predate Flow. They still run during the standard order of execution, and many production orgs rely on them every day:
Assignment Rules
Set the case owner (user or queue) when the case is created or updated. Each org can have multiple rules but only one active.
Auto-Response Rules
Send an email template back to the case contact at creation time. Often used to acknowledge web or email cases.
Escalation Rules
Time-based actions that run after creation. Reassign the case, notify users, or update fields when SLA criteria are missed.
When do the rules execute?
Case rules execute as part of the standard Salesforce order of execution, but the position matters. Assignment Rules fire before save (the case owner is set before before-save Flows run). Auto-Response Rules fire during save. Escalation Rules are separate — they’re evaluated by a time-based scheduler after the case has aged into the rule’s criteria.
Beyond the legacy rules, modern orgs increasingly use Flow Builder. Workflow Rules and Process Builder reached end of support on December 31, 2025 — Salesforce no longer accepts bug fixes or feature requests against them. Existing rules continue to execute, but all new automation must be built in Flow.
Don’t build new automation in Workflow Rules or Process Builder, even if your org still has them enabled. Use Flow Builder. Salesforce provides a “Migrate to Flow” tool in Setup to convert legacy workflows declaratively.
Einstein Case Routing
Einstein Case Routing is the AI-powered alternative to manual rule-writing. It analyzes historical case data and predicts the best queue, owner, or skill for incoming cases. Setup requires the Service Cloud Einstein feature license and at least a few thousand historical cases for the model to train on. Once active, Einstein routing can be invoked from an Omni-Channel Flow or run automatically at case creation.
Knowledge Management for Faster Resolution
Salesforce Knowledge is the article and FAQ system embedded inside Service Cloud. Service reps search it from the case page; customers browse it from Experience Cloud sites; and Agentforce Service Agents query it as their primary source of truth. Three flavors coexist:
Classic Knowledge
- Original article-type-per-record-type model
- Salesforce Classic-only authoring
- Salesforce recommends migration
- Lightning Knowledge Migration Tool available
Lightning Knowledge
- Single
Knowledge__kavobject with record types - Lightning Experience authoring
- Data Categories for organization
- Multi-language translation workflow
Beyond Lightning Knowledge, Salesforce introduced Enterprise Knowledge (generally available) — a next-generation knowledge platform that adds Agentic Enterprise Search (AES) and integrates with Data 360 to unify external knowledge sources. Unified Knowledge can pull articles from third-party systems (SharePoint, Confluence, Zendesk) through Data 360 connectors, making them searchable inside Salesforce without migration.
Article lifecycle
- Draft — Authors create articles in Lightning Knowledge with rich text, smart links, and embedded images.
- Review & Approve — Optional flow-based approval process before publication.
- Publish — Article becomes visible to assigned channels (Internal, Customer, Partner, Public).
- Translate — Multi-language support via export/import workflow or in-platform translation.
- Archive — Outdated articles are archived (not deleted) for compliance.
Knowledge visibility on the case page is controlled by Suggested Articles and Data Category Mapping. Suggested Articles uses the case Subject and Description to surface relevant content. Data Category Mapping pre-filters articles by case field values so reps see only what’s relevant to that case’s category.
The Service Console: Where Service Reps Work
The Service Console is the Lightning App that service reps live in. It’s a workspace-style UI — multiple cases open as workspace tabs, related records as subtabs, all with persistent utility bars at the bottom. Out of the box, the Service Console app includes:
- The Omni-Channel utility — accepts new work items, shows current capacity, tracks presence status
- The History utility — recent cases and records for quick recall
- The Notes utility — quick scratch notes attached to whatever record is open
- The Macros and Quick Text utilities — for repeatable actions and canned responses
- The Knowledge component — search and insert articles into emails and cases
- Case Feed — chronological activity timeline per case
Productivity features inside the console
Macros automate multi-step actions — send an email, change status, add a comment, all in one click. Quick Text provides reusable response snippets that can be inserted into emails and comments by typing a shortcut. Lightning Email Templates standardize outbound communications with merge fields and HTML formatting.
The Service Console also surfaces Record Alerts — contextual notifications that appear on a case or account when something needs the rep’s attention (e.g., “VIP customer,” “Open billing dispute”). Alerts are configured via Setup and integrate with Flow for dynamic triggers.
Customize the Service Console’s compact layouts before rollout. Compact layouts control what reps see in workspace tabs, hover cards, and the Omni-Channel new work notification. A poorly designed compact layout means reps have to click into the record just to know who’s calling.
Entitlements, Milestones, and SLA Management
Service contracts in Salesforce are modeled with Entitlements and Service Contracts. An Entitlement defines the level of support a customer is entitled to (e.g., “24/7 Premium Support”) and links to an Account, Contact, or Asset. A Case inherits its entitlement from the related account, and the entitlement controls which Milestones apply.
Milestones
A Milestone is a time-based commitment inside an entitlement — “First Response within 1 hour,” “Resolution within 24 hours.” Milestones display on the case page with a countdown timer and trigger workflow when completed or violated. They’re the mechanical implementation of an SLA.
| Object | Purpose |
|---|---|
EntitlementProcess | The sequence of milestones a case progresses through |
MilestoneType | The definition of a milestone (name, recurrence, time triggers) |
Entitlement | The actual service contract record linked to a customer |
CaseMilestone | The instance of a milestone on a specific case |
SlaProcess | SLA tracking metadata at the account or contract level |
Milestones can be associated with Business Hours so they pause overnight, on weekends, or during configured holidays. This is how SLAs avoid penalizing the service team for time when no one was on duty.
Incident Management and Customer Service Swarming
When a single issue affects many customers — a service outage, a recalled product, a payment processor failure — handling each case in isolation is wasteful. Customer Service Incident Management addresses this with three new objects:
Incident
The disruption itself. Multiple cases link to one incident, sharing status and updates.
Problem
The root cause behind one or more incidents. Survives even after the incident is resolved.
Change Request
A planned change to address a problem. Tracked through standard change management workflow.
The natural flow is Case → Incident → Problem → Change Request. A customer reports an issue (Case). The support team realizes other customers are reporting the same thing and creates an Incident, linking the cases. Engineering investigates and identifies the underlying Problem. A Change Request is filed to fix it. Throughout, Broadcast Communications push status updates to every linked customer.
Customer service swarming
Swarming is Salesforce’s framework for cross-functional collaboration on high-severity issues. When a swarm is started on a case or incident, designated experts from other departments — engineering, finance, ops — are pulled in to collaborate in real time, typically through a Slack channel. Swarming integrates with Slack for the communication layer and with Salesforce for the record context.
The distinction between a Case and an Incident is the scale of impact. One customer’s report is a Case. The underlying disruption affecting many customers is an Incident. Cases roll up to Incidents; Incidents roll up to Problems.
Agentforce Service Agents and the AI Layer
The reason “Service Cloud” was renamed “Agentforce Service” is the dramatic expansion of the AI layer over the past two releases. AI in Service Cloud now spans three roles:
AI for the service rep (assistive)
Einstein for Service includes case classification, work summaries, reply recommendations, and article recommendations. Service Replies drafts an email reply for the rep based on case context. Work Summaries auto-generate case summaries when a case is closed. These are assistive features — the rep stays in control and edits the output.
AI for the customer (deflection)
Enhanced Bots are scripted conversational flows that handle simple customer questions before a human is engaged. Bots run on dialogues and intents and can escalate to a service rep when they can’t resolve the issue.
AI as the service rep (autonomous)
An Agentforce Service Agent is an autonomous AI agent that can resolve cases without human intervention. It uses generative AI grounded in Knowledge articles, plus configured Topics and Actions that let it update records, send emails, or trigger flows. Agentforce Service Agents are a first-class routing destination in Enhanced Omni-Channel — they appear alongside human reps in the queue and pick up work items just like a person would.
An Omni-Channel Flow can route low-complexity cases to an Agentforce Service Agent and escalate to a human rep when the AI’s confidence drops or specific keywords appear. The handoff carries full conversation context so the customer doesn’t have to repeat themselves.
Agentforce Service Agents also work alongside the new Agentforce Contact Center, an all-in-one contact-center add-on generally available to Agentforce Service customers in the U.S. and Canada. It bundles voice, AI, and CRM into a single platform, eliminating the need for separate telephony integrations.
Supervising the Floor: Command Center for Service
The supervisor experience used to be called “Omni Supervisor.” Salesforce renamed it Command Center for Service and expanded what it shows. Command Center is the live operational view of everything happening in Service Cloud:
| Tab | What it shows |
|---|---|
| Wallboard | Real-time KPIs across queues, channels, and reps |
| Service Reps | Each rep’s current status, capacity, in-progress work, after-conversation time |
| Queues Backlog | Pending work by queue, with age and priority |
| In-Progress Work | Every active work item with rep, channel, and elapsed time |
| Skills Backlog | Pending work by required skill — useful for skills-based routing diagnostics |
| Agentforce | AI agent activity, resolution rates, handoff frequency |
| Reports | Embedded Service reports and dashboards |
Supervisors can reassign work manually, change a rep’s queue or skill membership on the fly, whisper to a rep during a call, and pull historical reports — all from Command Center. With the latest Agentforce integration, supervisors can also instruct an AI agent to update a rep’s assignments using natural language (“Move the Spanish-speaking reps to the billing queue for the next two hours”).
Configure Supervisor Configurations to tailor what each supervisor sees in Command Center. A queue lead doesn’t need the Agentforce tab; a contact center director needs all of them. Custom tabs and custom actions extend the experience without code.
12 high-yield Service Cloud facts
- Service Cloud = Agentforce Service. Spring ’26 docs use both names. The product, license SKUs, and existing exams continue to reference “Service Cloud.”
- Case is the central object. Sales Cloud includes basic Case functionality (Web-to-Case, Email-to-Case, basic escalation); Service Cloud adds Omni-Channel, Knowledge, Entitlements, and the Service Console.
- Standard vs Enhanced Omni-Channel. Enhanced is required for MIAW, Voice, Agentforce Service Agents, and Enhanced Bots. Standard is maintenance-only — new orgs should start with Enhanced.
- Five routing destinations: Queue, Skill, Support Rep, Agentforce Service Agent, Bot. AI Agents and Enhanced Bots require Enhanced Omni-Channel.
- Four routing methods: Basic Routing, Omni-Channel Flows (advanced), Skills-Based Routing Rules, Omni-Channel Unified Routing (for Voice).
- Three case automation rule types: Assignment (sets owner at creation), Auto-Response (sends email to contact), Escalation (time-based reassignment). Workflow Rules and Process Builder reached end of support December 31, 2025 — use Flow for all new automation.
- Three Knowledge tiers: Classic Knowledge (legacy), Lightning Knowledge (current), Enterprise Knowledge (next-gen with AES + Data 360 integration via Unified Knowledge).
- Entitlement Process drives Milestones. Milestones use Business Hours to pause overnight and on holidays. The
CaseMilestoneis the per-case instance of aMilestoneType. - Case vs Incident vs Problem. One customer = Case. The disruption affecting many customers = Incident. The root cause = Problem. Multiple Cases link to one Incident; multiple Incidents link to one Problem.
- Swarming is for cross-functional collaboration on high-severity cases or incidents. Integrates with Slack for communication and Salesforce for record context.
- Agentforce Service Agents are autonomous AI grounded in Knowledge. They’re a routing destination in Enhanced Omni-Channel and appear in the Agentforce tab of Command Center.
- Command Center for Service (formerly Omni Supervisor) has seven tabs: Wallboard, Service Reps, Queues Backlog, In-Progress Work, Skills Backlog, Agentforce, Reports.
Frequently asked questions
Yes. Salesforce officially rebranded Service Cloud as Agentforce Service. The Spring ’26 help documentation now describes cases as the backbone of Agentforce Service, formerly Service Cloud. The product, objects, APIs, and licenses are the same — only the brand has changed. Most customers, partners, and exams continue to use the Service Cloud name colloquially, and Salesforce uses both names interchangeably across its current materials.
Sales Cloud centers on the Lead, Opportunity, and Account objects to manage the pre-sale pipeline. Service Cloud centers on the Case object to manage post-sale customer issues. Sales Cloud includes a stripped-down version of Cases (Web-to-Case, Email-to-Case, basic escalation) for organizations without a dedicated support team. Service Cloud adds Omni-Channel routing, Knowledge, Entitlements, the Service Console app, Incident Management, and Agentforce Service Agents.
Standard Omni-Channel is the original routing engine for cases, leads, and custom objects. Enhanced Omni-Channel is the newer architecture required for messaging channels, voice, Agentforce Service Agents, and Unified Routing. Enhanced uses Pending Service Routing (PSR) records and supports Omni-Channel Flows as the routing brain. Salesforce recommends Enhanced for any new implementation; existing Standard orgs can upgrade following the official migration guide.
Assignment Rules set the case owner (user or queue) at the moment of creation. Auto-Response Rules send an outbound email template back to the contact who filed the case. Escalation Rules run on a time-based clock after case creation and can reassign the case, notify users, or change fields if SLA criteria are missed. All three are case-specific automation built before Flow existed, and they still execute as part of the standard order of execution.
A Case represents one customer’s report of an issue. An Incident represents the underlying disruption that may be affecting many customers at once — a system outage, a defective product batch, a service disruption. Multiple Cases can be linked to a single Incident. Incident Management adds the Incident, Problem, and Change Request objects alongside Case, plus customer service swarming for cross-functional collaboration on high-severity issues.
Lightning Knowledge ships with Service Cloud at no additional license cost. Enterprise Knowledge (the next-generation knowledge base with Agentic Enterprise Search and Unified Knowledge from external sources via Data 360) is generally available and may carry additional licensing depending on volume and connector usage. Classic Knowledge still exists in older orgs but Salesforce recommends migrating to Lightning Knowledge using the Lightning Knowledge Migration Tool.
An Agentforce Service Agent is an AI-powered autonomous agent that can resolve customer cases without human intervention. It uses generative AI, Knowledge articles, and predefined topics and actions to answer questions, update records, and take action on the customer’s behalf. Agentforce Service Agents are now a routing destination in Omni-Channel — alongside queues, skills, support reps, and bots — and are monitored from the Agentforce tab in Command Center for Service.
Wrapping up
Service Cloud (now Agentforce Service) is no longer just a case management product. The Case object is still the spine, but the body around it has grown — Omni-Channel handles every channel, Knowledge powers both reps and AI, Incident Management coordinates disruptions, and Agentforce Service Agents are quietly resolving cases at scale. Mastering the product means understanding how all of these layers cooperate, where the dividing lines between Standard and Enhanced sit, and which capabilities require which licenses.
For practitioners, that means staying current with at least the last three releases. For certification candidates, it means recognizing that the Salesforce certification track tests both the long-established mechanics (Cases, rules, entitlements) and the newer architecture (Enhanced Omni-Channel, Agentforce). You can browse all Salesforce certifications on CertifySF to find the exam that maps to your role.
All information verified against the official Salesforce Spring ’26 help documentation (release 262.0.0) at help.salesforce.com. Study smarter at CertifySF.com.
