Service Cloud · case ownership
One client, two answers.
Owning a case does not stop a colleague replying.
Salesforce lets any agent edit or answer a case another agent owns whenever case sharing is Public Read/Write, a common choice when the whole team must see every case, so the owner field is a label and not a lock. To make ownership hold, give the team a Take it action and refuse every edit and every outgoing email from anyone who is not the owner. This is what each sharing setting really allows, and how that rule was built and tested for an insurance agency in the US.
Salesforce Help read on 1 November 2026. Reviewed 3 November 2026.
The cause
Why can any agent edit or reply to a case they do not own?
Because in Salesforce the owner decides who is responsible, and sharing decides who may edit. With case sharing at Public Read/Write, every user can view, edit and report on every case, whoever owns it. Taking a case from a queue changes the owner and nothing else, so nothing stops a colleague answering the same client.
The four settings are defined in Organization-Wide Default Access Settings, and who may take a case from a queue under each of them is in Assign Cases. Read the last column before choosing.
| Case sharing | Who can take a case from a queue | Who can edit a case someone else owns | What it means for the team |
|---|---|---|---|
| Public Read/Write/Transfer | Anyone, from any queue | Anyone | Ownership is a label. This is the setting that looks friendliest and protects nothing. |
| Public Read/Write | Members of that queue, and people above them in the hierarchy | Anyone | Everyone sees every case, which a small team wants, and anyone can answer it. |
| Public Read Only | Members of that queue, and people above them in the hierarchy | The owner and the people above the owner | Edits are protected, but the team still has to see every case to cover for each other. |
| Private | Members of that queue, and people above them in the hierarchy | The owner and the people above the owner | Colleagues cannot even see a case when the owner is out and the client calls. |
Two more lines from the same pages matter. Taking ownership needs only Edit on cases, and Salesforce documents that, depending on sharing settings, only queue members and users above them in the role hierarchy can take records from a queue, per Create Queues. Neither says anything about who may send the client an email.
The rule
What should happen when an agent takes a case from the queue?
The agent becomes the owner, the status moves to In Progress, and from that moment only that agent can edit the case or email the client. Anyone else gets a plain message instead of a silent second answer. Handing the case on is a separate action that asks why, so a move never happens by accident.
The rule needs one more decision: the queue keeps the case until somebody takes it. Assigning each email to a named person on arrival is the other common design, and why it loses work is in the insurance agency case study. Here are the three messages agents see, word for word as they run in production:
One build, from the inside
Eight parts, in the order they were built.
A commercial lines agency in the US, policies kept in Applied Epic, every service email a case in a team queue. The desk runs on these rules, and certificate requests use the same Take it, as described in certificate requests as their own case type.
- 01
Take it, one action on the case
A screen flow behind a quick action sets the owner to the agent, stamps who took it, moves the status to In Progress and lets the agent set the request type on the same screen. It is offered only while a queue the agent belongs to owns the case.
- 02
Change Owner, with a reason nobody can skip
Handing a case on goes through a second action, open to the current owner and to managers. The new owner is chosen and a comment is mandatory; the comment is saved on the case, so whoever picks it up reads why it moved instead of asking.
- 03
One check in Apex on every case save
A before update trigger compares the old and new owner with the person saving. A legitimate change flips a hidden checkbox that only the two actions touch, so the trigger can tell Take it from someone typing their own name into the owner field.
- 04
The same check on every outgoing email
Blocking edits and not replies changes nothing, because an email is a separate record. The check runs again before an outgoing email is inserted on a case. The owner is read in a small inner class without sharing, so the answer does not depend on what the sender can see.
- 05
Queue membership through nested groups
Agents sit in queues through public groups, and groups inside groups. Membership is collected level by level, one query per level, never one query per case, so a bulk update of 200 cases does not run out of queries.
- 06
Who passes, and why
Administrators, the automated process user and integrations pass. Reception changes the request type without taking the case, and two managers reassign owners. The first version recognised administrators by profile name; I would now use a custom permission, which survives a renamed profile.
- 07
Merge, routing and leads
Merging two cases fails its own check, so the merge service makes the current user owner of both and excludes them in the same transaction. Setting the type to Claim moves the case to the Claims queue. The same Take it runs on leads with a sales queue.
- 08
The owner hears about a client reply
A new email on a case notifies its owner only when the owner is a person. While a queue owns it, nobody gets a message, because the queue list is where the team already looks. On the tablet the buttons were missing until they were rebuilt as Lightning quick actions.
Check it yourself
How do you test that only the owner can reply?
With two test agents, A and B, in the same queue and a third, C, in Claims. Run every row in a sandbox and write down what happened. If B can still send an email on A’s case, the rule covers edits only, and clients will keep getting two answers however the edit check behaves.
| Test | Expected |
|---|---|
| A edits a Customer Service case without taking it | The Take It message |
| A presses Take it | Owner A, status In Progress |
| B edits the case A now owns | Access denied |
| B replies to the client by email on that case | Access denied, the email is not sent |
| A types a new owner into the owner field | The Change Owner message |
| A uses Change Owner to B, with a comment | Owner B, the comment saved on the case |
| C, from Claims, tries Take it on a Customer Service case | The action is not offered, or Access denied |
| A sets the type to Claim | The case moves to the Claims queue |
Afterwards delete the test cases and deactivate the three users. Merge gets its own test, because a merged case is also a reply that lost its owner; the other ways one request turns into two cases are in five causes of duplicate cases from Email to Case.
Asked often enough to answer here
Questions
- Q
Can a validation rule do this without code?
Partly. A validation rule on Case can refuse a save by anyone who is not the owner. It never sees the reply, because an outgoing email is its own record and saving it does not save the case. That is why this build runs one check in Apex on both.
- Q
What happens to a case when its owner is on leave?
A manager moves it with Change Owner to a colleague or back to the queue, and writes why. Nobody has to log in as the absent agent, and the comment on the case tells the next person what was promised to the client.
- Q
Why not set case sharing to Private?
Because the team has to see a colleague’s case when the client calls about it. Private hides the case from everyone outside the owner’s line of managers. Keeping cases visible and refusing edits from anyone but the owner gives the team both.
Take it needs the queues that the first stage builds. It is stage 7 of the eleven on the insurance agency page, each priced on its own, and none of them needs Applied Epic replaced or integrated.
Serhii Skrypnyk · Senior Salesforce Administrator · 7 Salesforce certifications · on the platform since 2018. Reviewed 3 November 2026.
Read next
The question that usually comes after this one.
- 01
Email to Case Duplicate Cases and Loops
Why Salesforce Email to Case is creating duplicate cases or an auto response loop: five causes, two queries that tell them apart, and the closed case decision.
- 02
Salesforce Permissions Audit: Fixed €650
Nine access risks a Salesforce permissions audit finds and why agents inherit them all. Check them yourself, or one fixed day at €650 against your exports.
- 03
Case: Insurance agency, United States
Client service moved from shared inboxes to queues: every email a case with one owner, the request type read from the message, policy changes that cannot skip a step, Applied Epic kept.