Service
Service in Salesforce refers to the customer service side of the platform, the tools and data model that let support teams capture, route, and resolve customer requests.
Definition
Service in Salesforce refers to the customer service side of the platform, the tools and data model that let support teams capture, route, and resolve customer requests. It is delivered through Service Cloud, the product built around the Case object and a workspace where agents handle questions across email, phone, chat, and messaging.
In practice, "Service" is the umbrella for everything a support organization touches in Salesforce. That includes cases, knowledge articles, entitlements and milestones, omni-channel routing, and the Service Console agents work from. Where Sales Cloud is organized around closing deals, Service is organized around helping the customer after the sale.
How Salesforce structures customer service
The Case is the center of everything
A case is a record that represents a customer issue or request, and it is the object the rest of Service is built around. When someone emails support, fills out a web form, opens a chat, or calls in, the work usually lands as a case so an agent can track it through to resolution. The case holds the subject, description, status, priority, and the contact or account it belongs to. Cases pull related records into one place. Knowledge articles get attached for resolution, entitlements confirm the customer is covered by a support agreement, and milestones track whether the team is meeting its response and resolution targets. The Case Feed shows the history as a timeline, so every email, comment, status change, and call note sits in chronological order on the record. Because the case is a standard object, it works with the rest of the platform. Reports and dashboards run on case data, flows automate routing and field updates, and validation rules keep data clean. Most Service implementations start by deciding how cases get created, who owns them, and what "closed" actually means for each support team.
Channels: how cases come in
Service is designed to capture requests from wherever customers reach out, then turn them into cases your team can work. Email-to-Case converts inbound support emails into case records and keeps the email thread attached. Web-to-Case generates cases from a form on your website or help center. Beyond those, Service supports phone through Service Cloud Voice, live chat, and messaging channels like SMS and WhatsApp. The point of consolidating channels is that an agent does not have to bounce between separate inboxes and tools. A customer might start by emailing, follow up over chat, and call later, and all of it can attach to the same case or the same contact. That continuity is what lets a support rep answer with context instead of asking the customer to repeat themselves. Each channel has its own setup, but they feed a common data model. That is why a report on "average resolution time" can span email, chat, and phone at once. When you plan a Service rollout, you usually pick the channels that match where your customers already are, then layer routing and automation on top of them.
Omni-Channel routing puts work in the right hands
Once a case or other work item exists, something has to decide which agent handles it. Omni-Channel is the routing engine that pushes work to reps based on their availability, capacity, and skills. Instead of agents cherry-picking from a queue, Omni-Channel assigns the next best item to a rep who is online and has room for it. Routing comes in two main flavors. Queue-based routing sends work to members of a queue, while skills-based routing sends work to reps who have the specific skills a case requires, such as a product line or a language. You can run both models in the same org. If a routing configuration uses skills-based rules, the queue's membership no longer drives assignment, and work goes to any available rep with the matching skills. Routing configurations also set priority and capacity, so urgent cases jump ahead and no one rep gets buried. For more involved logic, Omni-Channel Flow lets you route chats, voice, and messaging by running a flow that picks a queue, skill, rep, or bot. This is how large support teams keep work balanced without a manager assigning every case by hand.
The Service Console is the agent workspace
The Service Console is a Lightning console app built for fast-paced support work. It is a tab-based workspace where an agent can open several records at once and keep them all in view, so working five cases does not mean losing your place in any of them. Related records open as subtabs under the case they belong to, which keeps a customer's full context grouped together. A utility bar runs along the bottom of the console for the tools agents reach for constantly. Common utilities include History, Macros, the Omni-Channel widget for accepting routed work, and a softphone for calls. Because these live in the utility bar, they stay available no matter which case tab is open. The console is where Service features come together on one screen. An agent can read the Case Feed, attach a knowledge article, run a macro to handle a repetitive action, and reply to the customer without leaving the workspace. The goal is simple: cut the clicking and scrolling so reps spend their time resolving issues rather than hunting for the next screen. Most Service deployments give agents the Service Console as their home base.
Knowledge, entitlements, and milestones
Three pieces give Service its depth beyond raw case tracking. Salesforce Knowledge is the article base agents search and attach to cases, so a fix written once can be reused on every similar issue and, often, published to a self-service help center. Suggested articles can surface on a case automatically based on its details, which speeds up answers. Entitlements define the level of support a customer is owed. An entitlement might say a premium account gets phone support with a two-hour first-response target, while a standard account gets email only. Entitlements connect to accounts, contacts, assets, or service contracts, so the right service level applies to the right customer. Milestones are the timed steps within an entitlement process, like "first response" or "resolution," each with a target clock. Service tracks the clock on the case and can warn an agent or escalate when a milestone is at risk, which is how teams hold themselves to a service level agreement. Together these three turn Service from a place to log tickets into a system that enforces promises and gives agents the answers they need.
Service Cloud, Field Service, and where the term fits
"Service" is broad, and it helps to know where the boundaries sit. Service Cloud is the core product for case-based, mostly remote support: contact centers, help desks, and the agents working cases from a console. It is the product most people mean when they say a company "runs Service on Salesforce." Field Service extends that same foundation to work that happens on location, like installs, repairs, and maintenance. It adds objects such as Work Order, Service Appointment, Service Resource, and Service Territory, plus a scheduling optimizer that matches the right technician and skills to the right job. Field Service shares the Service data model but is built for dispatching people into the field rather than answering tickets from a desk. Agentforce now layers AI on top of both. AI agents can deflect routine cases, draft replies, and suggest next steps, while human agents handle the rest from the same console. When you scope a project, naming which slice of Service you mean, core Service Cloud, Field Service, or AI-assisted support, keeps the data model and licensing conversation honest.
Trust & references
Cross-checked against the following references.
- Service Overview, Data Model GallerySalesforce
- Set Up and Manage Cases in Service CloudSalesforce
Straight from the source - Salesforce's reference material on Service.
- Route Work with Omni-ChannelSalesforce
- Salesforce Console (Service Console)Salesforce
Hands-on resources to go deeper on Service.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Service in Field Service?
Q2. What do services link to?
Q3. Why do service definitions matter?
Discussion
Loading discussion…