Presence Status
A Presence Status is an Omni-Channel setting that shows whether a service representative is available to receive routed work.
Definition
A Presence Status is an Omni-Channel setting that shows whether a service representative is available to receive routed work. Each status is one of two kinds, Online (the rep can accept work) or Busy (the rep cannot), and reps switch between statuses through the day to signal what they are doing.
The status a rep selects is the signal the routing engine reads before it assigns a case, chat, or call. Set to an Online status, the rep is eligible for new work up to their configured capacity. Set to a Busy status such as On Break or In a Meeting, the rep is skipped until they return to an available status.
How presence statuses drive Omni-Channel routing
The two status kinds: Online and Busy
Every presence status you create belongs to one of two kinds, and that choice decides everything about how the status behaves. An Online status means the rep is open for routed work. Omni-Channel can push cases, chats, messaging conversations, and voice calls to anyone sitting in an Online status, as long as they have spare capacity. A Busy status means the rep is logged in but not taking new work. Reps move to a Busy status for breaks, meetings, training, or wrap-up time on a tough case. You are not limited to one of each. Most contact centers build several Online statuses and several Busy statuses so the labels match real operations. You might have one Online status named Available for All Channels and a separate one named Chat Only. On the Busy side you might create On Break, Lunch, Training, and After-Call Work. The kind (Online or Busy) controls the routing behavior. The name is just a label your reps and supervisors see.
Statuses, service channels, and configurations are three different things
Presence Status is easy to confuse with two neighboring settings, so it helps to separate them. A presence status answers the question "can this rep take work right now." A service channel defines a type of work, such as cases or chats, and ties an object to Omni-Channel. A presence configuration sets how much work a rep can hold at once, their capacity, plus options like whether they can decline a request. When you build a presence status, you choose which service channels it allows. That is how you create a Chat Only status: it is an Online status that permits the chat service channel but not the case channel. The presence configuration is assigned to the rep, not to the status, and it carries the capacity number. So routing reads three things together: the rep is in an Online status, that status allows the channel the work belongs to, and the rep has capacity left under their presence configuration. Miss any one and the work goes elsewhere.
Access is granted through profiles and permission sets
Creating a presence status does not make it usable. A rep can only select statuses they have been granted, and you grant them through a profile or a permission set. This is deliberate. It lets you give a tier-one team the everyday statuses while a specialist team sees an extra status like Escalations Only. After you create your statuses, open the relevant permission set or profile and add the presence statuses under Enabled Service Presence Status Access. A common rollout mistake is finishing the status setup, assigning the Omni-Channel widget, then wondering why reps see an empty status menu. The statuses exist, but no one has access. Grant access as part of the same setup pass. If you use Salesforce Service Cloud Voice, the voice setup flow has its own step that creates a presence status and assigns it to users, so check there too before assuming a status is missing.
Capacity and the routing configuration must line up
Presence status decides whether a rep is eligible. The presence configuration and the routing configuration decide how much they receive. These numbers have to agree or work stops flowing in confusing ways. The presence configuration holds the rep capacity, often a points value like 5. Each service channel's routing configuration assigns a cost to its work items, the units of capacity an item consumes. The practical rule is that a single work item's capacity cost should be less than or equal to the rep's total capacity. If a chat costs 5 units and the rep only has 3, that chat can never route to them even while they sit in a perfectly valid Online status. Reps and supervisors often blame the status when nothing arrives, but the real block is the capacity math. When you troubleshoot empty queues, confirm the Online status first, then compare the routing configuration cost against the presence configuration capacity before looking anywhere else.
Status-based capacity changes what "Busy" means
The older capacity model counted open tabs and sessions. A newer option, the status-based capacity model, measures a rep's load by the status of the work they have accepted rather than by what is open on screen. This matters for presence because it changes when a rep is treated as full. With status-based capacity, a case the rep has accepted but parked in a waiting status can free up room for new work, where the older model would still count it against them. You do not have to use status-based capacity, and many orgs run fine without it. The point for presence is that capacity and availability are two layers. Presence status is the on or off switch the rep controls. The capacity model is the math underneath that decides how full an available rep already is. A rep in an Online status with no free capacity is just as unroutable as a rep on break, even though the status menu shows them as available.
Presence data tells you how reps spend their day
Every time a rep changes status, Omni-Channel records it. The UserServicePresence object captures who was in which status and for how long, with start and end timestamps. That history is the raw material for workforce reports. You can see total time Available versus On Break, how long After-Call Work runs, and whether a team spends more time in Busy statuses than planned. This is why naming matters more than it first seems. If every kind of unavailability hides behind one generic Busy status, your reports cannot tell coaching from lunch from system training. Split the reasons into distinct statuses and the data becomes useful. A worked example: a supervisor notices handle times creeping up. Pulling presence history, they find reps sitting in After-Call Work far longer than the target. That points to a knowledge gap or a clunky wrap-up macro, not a staffing problem. Without separate statuses, that signal would have been buried inside an undifferentiated Busy bucket.
How to create and assign a presence status
Presence statuses are configured in Setup under the service rep status area, then made usable by granting access through a profile or permission set. You build the statuses once, decide which service channels each one allows, and assign them to the right teams.
- Open the presence status setup
In Setup, go to Set Up Service Reps, then Set Up Service Rep Statuses and Capacity, then Create Presence Statuses. Click New to start a status.
- Name the status and pick its kind
Enter a Status Name your reps will recognize and let the Developer Name populate. Set the status to Online if reps in it should receive work, or Busy if they should not.
- Assign the allowed service channels
For an Online status, move the service channels this status should accept into the selected list. A status that allows only the chat channel becomes a Chat Only availability. Busy statuses take no channels.
- Grant access through profiles or permission sets
Open the permission set or profile for the team, find Service Presence Status Access, and enable the statuses they should see. Without this step the status menu stays empty for reps.
- Verify capacity lines up
Check that the rep's presence configuration capacity is at least the units of capacity each routing configuration assigns to its work items, so eligible reps actually receive work.
The label reps and supervisors see in the Omni-Channel widget, like Available, On Break, or Training.
The unique API name auto-generated from the Status Name, used in reporting and metadata.
Online makes reps eligible for routed work; Busy keeps them logged in but excluded from routing.
The work types an Online status accepts, such as cases, chats, messaging, or voice; this is how channel-specific statuses are built.
- Creating a status does not grant it. Reps see only the statuses enabled on their profile or permission set, so add access in the same setup pass.
- An Online status with too little capacity still receives nothing if a single work item costs more units than the rep's presence configuration allows.
- Folding every reason for being unavailable into one Busy status destroys your reporting; split breaks, meetings, and wrap-up into separate statuses.
- Service Cloud Voice setup creates and assigns its own presence status, so check that flow before assuming a voice status is missing.
Prefer this walkthrough as its own page? How to Presence Status in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Create Presence StatusesSalesforce
- Set Access to Presence StatusesSalesforce
Straight from the source - Salesforce's reference material on Presence Status.
- Create Presence ConfigurationsSalesforce
- Set Up a Status-Based Capacity ModelSalesforce
Hands-on resources to go deeper on Presence Status.
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 does an agent's Presence Status control in Omni-Channel?
Q2. What configurable property does each Presence Status carry?
Q3. When an agent sets Presence Status to On Break, what does Omni-Channel do?
Discussion
Loading discussion…