The Group That Can See Everything
An HR application has a record type EmployeeCase containing sensitive disciplinary data. Access is granted through a group HR Case Workers. The record type's security is set so that members of HR Case Workers can view all cases. A new requirement says case workers may only see cases where they are the assigned worker, plus their manager may see all cases in their team. The application also has a Case Notes related record type that inherits visibility from the parent case. There are 40 case workers across 6 teams, and team membership changes quarterly. Auditors have flagged that the current setup lets any case worker view any employee's disciplinary record.
1. How should record-level security be restructured to meet the requirement without hardcoding 40 users?
Read the worked answer
Move from group-level view access to row-level visibility driven by data, with groups used only for role capability.
- Keep
HR Case Workersas the group that grants the ability to use the application and the record type, but remove its blanket view permission on all rows. - On
EmployeeCase, set the record-level visibility so a user sees a row when they are the assigned worker or when their team matches the case's team and they hold a manager role. - Drive team membership from data, not from 40 hand-maintained groups: a
Teamrecord type (or ateamIdfield on the user profile) that the security expression reads. Quarterly changes then mean updating a data field, not editing group membership in 40 places. - Managers are identified by a role flag on the user record, not by a separate group per team.
The security expression should read from these data fields so that adding a worker or moving a team requires no security configuration change - only a data update.
2. What must be done about the `Case Notes` record type, and what is the risk if it is overlooked?
Read the worked answer
Case Notes currently inherits visibility from the parent EmployeeCase. If the parent's visibility is tightened to per-worker/per-team, the notes should follow - but this must be verified, not assumed. The risk is that Case Notes has its own group-based view permission that was added independently, which would leave notes visible to all case workers even after the parent case is locked down.
The correct step is to confirm that Case Notes visibility is expressed in terms of the related case (e.g., visible if the related EmployeeCase is visible to the user), and remove any standalone group grant. Then test with a user who is not the assigned worker: they should see neither the case nor its notes.
Auditors look for exactly this gap - locking the parent while leaving a child record type open. The fix is only complete when the child's access is derived from the parent's.
3. How would you prove to the auditors that the fix works, given 40 workers and 6 teams?
Read the worked answer
Produce evidence from negative testing, not just positive testing. The prior setup passed positive tests (a case worker could see their case) while failing the actual requirement (they could see everyone's).
Test matrix:
- Assigned worker → sees own case and notes. ✔
- Non-assigned worker on the same team → sees neither. ✘ (must be denied)
- Manager of the case's team → sees the case and notes. ✔
- Manager of a different team → sees neither. ✘
- Administrator → sees all, as designed. ✔
Run each as a real user account, capture the results, and repeat after a simulated quarterly team change to prove the data-driven model responds without security edits. Document the security expression and the data fields it depends on so the auditors can see the rule, not just a screenshot.