Least-Privilege Case Sharing Across Pods, Regions, and a VIP Queue
Meridian Insurance runs a 600-agent service center in a single business unit. Case organization-wide default is Private. The role hierarchy is Region, then Team Lead, then Agent. Agents must see their own cases plus all cases owned by their eight-person pod so they can cover absences. Team leads need their pod's cases, and regional managers need everything in their region. A new compliance team of five analysts must read every closed case tagged Complaint, including attachments, but must not see open cases or any other case type. Separately, a VIP queue holds high-value claims that any of 20 senior agents may pick up, regardless of region. Since go-live, agents have been given a View All Data permission set as a workaround, new hires can see far more than intended, and an audit found 37 cases opened by agents outside their region with no business justification. Reports also show pod members cannot see each other's cases unless someone manually shares them.
1. Design the least-privilege sharing model for agents, team leads, and regional managers. State which mechanism you use for each requirement and why.
Read the worked answer
Design each access shape with the mechanism that matches it, rather than one blunt tool:
- Base access: keep Case organization-wide default Private. Do not loosen to Public Read/Write; that would defeat every other control.
- Hierarchy-shaped access: keep the Region, Team Lead, Agent role hierarchy. Team leads see downward to their pod; regional managers see their region. This needs no sharing rules and does not break when people move.
- Pod peer access: create a Team per pod and share cases to the team with Read/Write, or use a criteria-based sharing rule on a stable Pod field. Prefer teams when membership changes often, because team membership is maintainable; prefer criteria rules when the pod is derived from a field that rarely changes. Manual sharing is not a primary mechanism, since it does not scale and breaks on ownership change.
- VIP queue: implement a Queue with the 20 senior agents as members. Queue membership grants access to queued cases; once an agent accepts, ownership transfers and access follows ownership. Agents outside the queue never see those cases.
- Why not one mechanism: role hierarchy solves vertical access, teams or queues solve horizontal access, sharing rules solve criteria-based access. Using the wrong one produces either overexposure or maintenance debt.
Then remove the View All Data workaround and re-audit access before declaring the model complete.
2. Explain why the View All Data permission set is the wrong fix, and outline the remediation. What likely explains new hires seeing too much?
Read the worked answer
View All Data is a system permission, not a sharing grant. It bypasses sharing for the objects it covers, cannot be scoped to a region, pod, or case type, and is invisible in record-level sharing audits. It also tends to be bundled into a permission set group or profile, so it spreads silently. That matches the symptom of new hires seeing far more than intended: they inherited the permission through an assigned group or a cloned profile rather than through a deliberate grant.
Remediation:
- Inventory every holder of View All Data and Modify All Data, including users who inherit it through permission set groups.
- Map each holder to a legitimate need: compliance, integration, or data stewardship. For everyone else, remove it and replace with targeted sharing, teams, queues, or criteria-based rules.
- Rebuild the access model before removal, so removals do not create outages that trigger a rollback.
- Enable field history and login or event monitoring on the Case object so future overexposure is detectable.
- Run a sharing audit and a sample of 'login as' checks for new hires and recent transfers.
- Add a release checklist item: any permission set granting View All Data requires security approval.
The 37 cross-region cases suggest agents were opening cases they could see but had no reason to act on; fix visibility first, then coach behavior.
3. How would you give the five compliance analysts read access to closed Complaint cases and attachments without exposing anything else?
Read the worked answer
Use criteria-based sharing rather than a broad permission:
- Create a public group, for example Compliance Analysts, containing the five users.
- Create a criteria-based sharing rule on Case: Status equals Closed AND Type equals Complaint, shared to that group with Read Only. Criteria sharing evaluates at save time and grants exactly the matching records, not all closed cases and not open ones.
- Confirm the criteria are mutually exclusive enough to avoid drift. If Complaint is a case record type or a picklist value, decide which is authoritative and keep only one.
- Attachments and files generally inherit access from the parent case when the file is attached to the record, so Read Only on the case should cover them. Verify whether files are stored as Salesforce Files with their own sharing; if so, check the file sharing behavior and test with a real attachment.
- Do not use View All Data for this team. It would expose every object and every case, and cannot be limited to closed complaints.
- Apply field-level security if the complaint cases carry sensitive fields the analysts do not need, such as payment data.
- Re-test when case status changes; a case that reopens should drop out of their visibility, which criteria sharing handles automatically.
- Add a quarterly access review, since the group will change as analysts join and leave.
This gives the smallest grant that satisfies the audit requirement and keeps open investigations private.