Case, Checkout
A Case Checkout is the Service Cloud workflow pattern where a service representative explicitly claims a Case from a shared Queue by taking ownership of it before starting work.
Definition
A Case Checkout is the Service Cloud workflow pattern where a service representative explicitly claims a Case from a shared Queue by taking ownership of it before starting work. The act of checkout changes the Case Owner field from the Queue to the individual rep. That single change signals to the team that the Case is now being handled, and it stops two people from working the same record at once.
Case Checkout is not a single button or object name in Salesforce. It is the operational concept behind several built-in features: the Accept button on Queue list views, Change Owner actions, and Omni-Channel routing that assigns work automatically. Older Service Cloud material and partner blogs use the phrase Case Checkout, while current Salesforce documentation describes the same behavior as taking ownership of a record or accepting a routed work item.
How agents claim a Case in Service Cloud
Queues hold the shared pool of work
A Queue lets a team share its workload. Cases assigned to a Queue, rather than to a named user, collect in a list that every Queue member can see. Salesforce describes this directly: a Queue lets a team of users share their workload, and records appear in a list where any member of the team can take ownership of a record. Assignment rules, Email-to-Case, Web-to-Case, or manual edits route new Cases into the right Queue. For example, a hardware support Queue and a software support Queue can each hold the Cases their team owns. Until someone claims a Case, the Queue itself is the Owner value on the record. This is the starting state that every checkout pattern resolves. Membership controls visibility and eligibility, so adding a rep to a Queue is what lets that rep pull from it. Without Queues, incoming Cases would land on a single default owner and lose the shared-pool model that checkout depends on. Queues are the foundation, and checkout is the action that moves a Case out of the pool and onto one person.
Take ownership with the Accept button
The manual checkout pattern is the Accept button on a Queue list view. When a list view shows records owned by a Queue, Salesforce adds an Accept button. Clicking it assigns the current user as the Owner of the selected Cases, and any attached open activities transfer to that user too. The Case leaves the Queue list because it now has an individual Owner. Not everyone can take ownership. A user can claim a Case if they are a member of that Queue, if they sit higher in the role or territory hierarchy than a Queue member, or if the org default sharing for Cases is Public Read/Write/Transfer. The Accept button only appears when the list view is filtered by a Queue owner, so an admin sets up the view with the Filter by Owner option set to that Queue. This is the closest thing to a literal Case Checkout control in standard Salesforce. It is simple, visible, and works well for low to moderate volumes where reps choose their own next Case.
Omni-Channel as automated checkout
Omni-Channel turns checkout into a push model instead of a pull model. Rather than reps scanning a list and clicking Accept, Omni-Channel routes a Case to a specific available rep based on presence status, capacity, and Queue or skill rules. The rep sees a notification in the Omni-Channel widget and accepts the work by clicking the checkmark, which opens the Case in a console tab. From the reporting and customer point of view, the result matches manual checkout: one Owner per Case, claimed at a known moment. The difference is that the system, not the rep, decides which Case comes next. If a rep does not accept a routed item, Omni-Channel tries to reroute it to the next available rep using the configured model, such as Least Active or Most Available. Routing respects each rep capacity so no one is handed more than they can hold. For high-volume Queues, this push model scales far better than manual Accept, because it removes the cherry-picking and the race conditions that come with many people watching one list.
Preventing a double checkout
The whole point of checkout is one Owner per Case at any moment, so blocking a double claim matters. Omni-Channel handles this by design. It assigns a routed work item to a single rep, so two reps cannot accept the same item. Manual Accept relies on standard record locking. If two users click Accept on the same Case at nearly the same time, the second click fails because the record was already reassigned. Custom checkout built in Apex or Flow needs more care. A button or screen Flow that simply updates the Owner field can let two simultaneous actions both succeed if neither checks the current Owner first. Developers guard against this with a SOQL FOR UPDATE lock to serialize access, or by re-reading the Owner inside the transaction and refusing the update when it is no longer the Queue. AgentWork records help here too, since the IsOwnerChangeInitiated field shows true when a work item Owner was changed manually, which makes audit and reporting on ownership changes possible after the fact.
Returning a Case to the Queue
Checkout is not always permanent. A rep may claim a Case and then find it needs a different skill, belongs to another team, or cannot finish before the end of a shift. The standard fix is to change the Case Owner back to the Queue. Salesforce supports this through the Change Owner action, which assigns the Case to a chosen user or Queue and transfers attached open activities to the new owner. Many teams surface this as a Return to Queue button or a Change Owner quick action on the Case page so the step is obvious and one click. In Omni-Channel, the equivalent is closing or reassigning the work item so it can be routed again. Treating return as a first-class, named workflow is what keeps Cases from getting stuck on a rep who cannot move them forward. Without a clear return path, an overloaded or mismatched rep tends to leave a Case sitting, which hurts the customer and hides the real Queue backlog from supervisors who watch the shared pool.
Measuring checkout time
Checkout produces a measurable moment, and that moment is worth reporting on. The gap between when a Case is created and when its Owner changes from the Queue to a rep is queue dwell time. It answers a direct question: how long do customers wait before anyone owns their Case? Low dwell time means the Queue is staffed and routing well. High dwell time points to a bottleneck, such as too few reps, capacity set too low, or a routing rule sending work to the wrong group. Reports built on Owner change history, or on Case fields that capture the assignment time, expose this clearly. With Omni-Channel, AgentWork records add precise detail, recording which reps accepted sessions and when, so supervisors can see accept times and rerouting in one place. Pairing dwell time with handle time gives a fuller picture, separating the wait before checkout from the work after it. These two numbers drive most staffing and capacity decisions for a Service Cloud team, so building the reports early pays off quickly.
Common pitfalls to plan around
A few patterns trip teams up. The first is manual Accept at high volume. When dozens of reps watch one Queue list, they cherry-pick easy Cases, race for the same record, and leave hard ones to age. Omni-Channel removes the choice and fixes most of this. The second is Omni-Channel with untuned capacity. Default capacity numbers rarely match real average handle time, so reps end up overloaded or idle. Tuning capacity per role against observed handle time is the fix. The third is custom checkout that updates the Owner field without firing the normal record-change events, or without checking the current Owner first. That can leave downstream automation silent and allow two reps to claim one Case. The fourth is having no clear return path, which strands Cases on the wrong rep. The last is forgetting that taking ownership requires the right access. If a rep is not a Queue member and sharing is restrictive, the Accept button will be missing and reps will report that they cannot claim anything from the Queue.
Set up Case Checkout in Service Cloud
There is no single Case Checkout setting. You enable the behavior either by giving reps a Queue list view with an Accept button, or by routing Cases through Omni-Channel. Here is the common path for both, starting from a Queue.
- Create a Case Queue
In Setup, open Queues and click New. Add a label and name, choose Case as the supported object, and add the reps or roles who should pull from this Queue as members. Membership is what lets a rep take ownership later.
- Route new Cases into the Queue
Use case assignment rules, Email-to-Case, or Web-to-Case so new Cases land in the Queue with the Queue as Owner. You can also let agents assign a Case to the Queue manually when editing it.
- Set up the Accept button for manual checkout
Build a Case list view filtered by Owner set to the Queue. When the list shows Queue-owned records, Salesforce adds the Accept button, which lets a member claim a Case and become its Owner in one click.
- Or enable Omni-Channel for automated checkout
Turn on Omni-Channel, create presence statuses and a presence configuration with capacity, and build a routing configuration that sends the Queue work to available reps. Reps then accept routed Cases from the Omni-Channel widget.
- Add a Return to Queue path
Give reps a Change Owner quick action or button on the Case so they can reassign a Case back to the Queue when it needs a different rep. This keeps misrouted Cases moving instead of stuck.
The Accept button only appears when the list view is filtered by a Queue in the Filter by Owner section. Without that filter, reps see no way to claim Cases.
A rep must be a Queue member, sit higher in the role or territory hierarchy, or rely on Public Read/Write/Transfer sharing to take ownership of a Case.
Presence statuses control which work a rep can accept, and capacity limits how many items route to them at once. Tune capacity to real average handle time.
Choose how unaccepted work reroutes, such as Least Active or Most Available, so a declined or timed-out Case moves to the next available rep.
- The Accept button is missing if the list view is not filtered by a Queue owner, or if the rep lacks the access to take ownership.
- Manual Accept invites cherry-picking and race conditions at high volume; prefer Omni-Channel once a Queue gets busy.
- Custom checkout that updates Owner without checking the current value, or without firing record-change events, can allow double claims and silence downstream automation.
- Default Omni-Channel capacity rarely matches real workload, so reps end up overloaded or idle until you tune it.
Prefer this walkthrough as its own page? How to Case, Checkout in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Queues OverviewSalesforce
- Route Work with Omni-ChannelSalesforce
Straight from the source - Salesforce's reference material on Case, Checkout.
- Route Work with Omni-ChannelSalesforce
- Create a Change Owner Quick Action for CasesSalesforce
Hands-on resources to go deeper on Case, Checkout.
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 the Case Checkout pattern accomplish for a shared service queue?
Q2. How does Omni-Channel act as automated Case Checkout?
Q3. Why does a custom checkout button need explicit locking that manual Take Ownership does not?
Discussion
Loading discussion…