A telco I worked with had a recurring complaint from its support managers: agents kept saying they "couldn't see" cases they were sure they should have access to, while compliance kept flagging the opposite problem, that the wrong people could see sensitive cases. When I sat down with their config, the root cause was predictable. Someone had tried to solve every collaboration requirement with Case Teams, including requirements that were really about whole categories of cases, and someone else had quietly flipped the Case org-wide default to Public Read/Write "to make things easier." The two decisions fought each other, and nobody could explain who could see what.
That project is a good lens for this whole topic, because Case Teams and case sharing are the two tools people reach for and constantly confuse. They overlap just enough to feel interchangeable, and they are not. One attaches a specific group of collaborators to one specific case. The other grants access to a whole class of cases based on rules. If you pick the wrong one, you either drown agents in manual work or you leak data, and on a regulated account you will hear about the leak first.
Before touching any of it, internalize the single most important principle: in Salesforce, access is additive. Org-wide defaults, role hierarchy, sharing rules, Case Teams, manual shares, and Apex sharing are all sources that grant access, and the platform always resolves to the highest level it finds across all of them. Nothing in this list ever takes access away. Once that clicks, most of the confusing behavior stops being confusing.
What a Case Team actually is, and when it earns its place
A Case Team is a set of users, contacts, or portal users attached to one individual case, each carrying a role and an access level. The classic scenario is an ATM dispute at a bank: a customer claims the machine debited their account but never dispensed cash. The tier-1 agent who took the call owns the case and keeps the KPI, but resolving it pulls in the ATM operations team to read machine logs, a risk and fraud investigator to check the transaction, the branch manager to confirm the cash balance, and a tier-2 relationship agent to call the customer back. Five groups touch one case, but only one of them owns it. That is exactly the shape Case Teams were built for.
You define Case Team Roles under Setup, each with a name and a Case Access level of Read Only, Read/Write, or Private. Read/Write lets the member edit fields, change status, and post comments. The Private level is a trap people misread constantly: it puts the member in the team list for tracking but grants no record access at all. There is also a "Visible in Customer Portal" flag per role, which matters more than it looks, and I will come back to it.
For repeatable processes, build a Pre-defined Case Team, which is a template of members and roles that gets applied in one action instead of adding people one at a time. You can apply it manually from the related list, or have a flow apply it automatically when the case matches a condition. At the bank we auto-applied the "ATM Dispute Standard" team whenever Type was ATM Dispute and Origin was a known channel, which covered the large majority of cases, and left agents to apply it by hand for the escalations that came in off-pattern. That split is usually the right instinct: automate the predictable bulk, leave a manual escape hatch for the exceptions.
One layout detail trips up almost every first implementation. Adding someone to a Case Team grants them record access immediately, but they will not see the team list on screen unless you drag the Case Team component or related list onto the Lightning record page. Managers then open a case, can't tell who is on it, and start asking around. The access was fine; the visibility was never configured.
The additive-access trap that generates the most support tickets
Here is the gotcha I flag in every Case Team design review, because it shows up on exams and, more importantly, in real "this is broken" tickets. Setting a Case Team role to Read Only does not restrict anyone. If the user is the case owner, or has Read/Write from a sharing rule, or sits above the owner in the role hierarchy, they keep editing the case regardless of what the team role says. Case Access only widens access; it never narrows it.
So when a client tells you "I set the risk investigator role to read-only but they can still edit," do not start by debugging the Case Team. Check the org-wide default, the sharing rules, the role hierarchy, and ownership first, because one of those is granting the higher level. If you genuinely need to prevent editing, that is a job for a validation rule or a permission set controlling field access, not for a softer Case Team role. There is no combination of sharing settings that subtracts.
The same additive logic explains the portal-visibility risk. The "Visible in Customer Portal" checkbox defaults to off for good reason. Tick it on for an internal role like risk investigator, and a customer logged into your Experience Cloud site will see "Risk Investigator: [employee name]" sitting on their own case. On a regulated account, compliance flags that the moment it hits production. Double-check every role's portal visibility before you ship.
Choosing between owner-based and criteria-based sharing
Case Teams handle the one-case collaboration problem. When the requirement is "everyone in this group should see every case of this kind," you have crossed into sharing rules, and that is a different mechanism entirely. Start by keeping the Case org-wide default on Private, which is the platform's own recommendation and the only sane choice when cases routinely hold account numbers, national ID numbers, or medical symptoms. Private means a user sees only the cases they own or inherit through the role hierarchy, and every other grant flows through an explicit rule.
From there you have two rule types. An owner-based rule says "cases owned by members of group or role X are shared to group or role Y," which is how you give a tier-2 team blanket read/write over everything tier-1 opens. The catch is that it keys off ownership, so reassigning a case re-evaluates the rule. A criteria-based rule instead says "cases where a field equals some value are shared to group or role Z," independent of who owns them, which is what you want for region- or type-based access where ownership is irrelevant. Reach for criteria-based when the access decision lives in the case data itself.
Criteria-based rules carry real limits worth knowing before you design around them. You get up to fifty per object, the criteria field can't be a text area or a multi-select picklist, and the rule only recalculates when a field on the case itself changes. That last point burns people: if your criteria field is a formula that pulls from a parent record, changing the parent does not retrigger the share. I have had to add a flow that writes a plain (non-formula) field in parallel just so the sharing rule has something it will actually react to.
For the cases that don't fit any rule, manual sharing covers the one-off. A specialist needs a second opinion, so the owner shares that single case to a colleague at Read level. The important behavior is that manual shares disappear automatically when the case owner changes, which is the opposite of what clients expect and a frequent "why did they lose access?" ticket. When you genuinely need a share to survive owner changes, or to depend on a cross-object lookup that criteria-based rules can't express, that is the signal for Apex managed sharing. You don't write the code as a functional consultant, but you do need to know the lifecycle: Apex shares need a custom sharing reason defined up front, and unlike manual shares they are not removed when ownership changes, so someone has to remove them deliberately.
Reading the sharing stack as one combined picture
The reason these mechanisms confuse teams is that any given user's access to a case is the sum of all of them at once. When a manager asks why someone can or can't see a case, walk the stack in order: View/Modify All at the profile or object level, then ownership, then role hierarchy (Grant Access Using Hierarchies is on and, for Cases specifically, cannot be turned off), then owner-based rules, then criteria-based rules, then Case Team membership, then manual shares, then Apex shares. The user's effective access is the highest level any of those grant.
I have walked a telco through exactly this when a tier-2 lead in one region couldn't see a high-priority case from another region. Ownership didn't reach them, the role hierarchy didn't connect across regions, the high-priority rule shared only to service managers, and the region-specific criteria rule didn't match because the case belonged to a different region. The honest answer was that least-privilege was working as designed, and the most convincing way to deliver that answer was a simple spreadsheet mapping each rule to who it touches. When access questions get political, that mapping is worth more than any verbal explanation.
A few stack-level traps are worth committing to memory. If an org sits on Public Read/Write and someone later wants to lock it down, every sharing rule has been meaningless up to that point and the switch back to Private forces a full recalculation that can freeze a large org for hours. Deeply nested public groups make membership slow to compute and nearly impossible to debug, so keep nesting shallow. And on very large orgs, adding a new rule triggers a full sharing recalculation that you should defer and run overnight rather than during business hours.
The discipline that holds all of this together is to name the problem before naming the tool. If the requirement is about one case and a known set of collaborators, it's a Case Team. If it's about every case matching some condition, it's a sharing rule, and you choose owner-based or criteria-based by asking whether the access depends on who owns the case or on what's in it. Get that first classification right and the rest of the configuration mostly falls out on its own; get it wrong and you'll spend the next sprint explaining to a frustrated manager why the platform is doing exactly what you told it to.
Implementing or optimizing Service Cloud? Our Salesforce team runs discovery, designs the case process, and configures Service Cloud, Omni-Channel, and Knowledge on production engagements. Get in touch ->
See our full platform services for the stack we cover.
