The Group Picker That Leaks Confidential Requests
An HR request process lets employees submit sensitive cases (grievances, accommodations). The process uses a dynamic group picker to route each case to 'HR Business Partner for the employee's department.' There are 12 department groups. During testing, an employee in Finance was able to see another Finance employee's grievance in their task list because both resolve to the same department group. The group has 9 members including two contractors. Leadership wants cases visible only to the assigned HRBP, not the whole department group, while keeping the ability to reassign when someone is out.
1. Why does the department-group routing leak cases, and what assignment model meets the confidentiality requirement while preserving reassignment?
Read the worked answer
Why it leaks. Routing to a group grants every member of that group visibility of every task assigned to it. 'HRBP for department' resolved to a 12-person (here 9-member) group, so all 9 - including contractors - can see all department cases. Group assignment is a pool, not a person. Sensitive cases must not be pooled.
Assignment model that meets the requirement:
- Assign to the individual HRBP, resolved from the employee's department (a one-to-one mapping dept → HRBP user), not to a group. The task then appears only in that person's queue.
- Preserve reassignment via a controlled override, not open group visibility:
- An out-of-office / backup mapping: a designated backup HRBP who receives reassigned tasks, defined per primary HRBP.
- Reassignment by an authorized role (e.g., HR manager) through an action that moves the task to a specific named user, with the move logged.
- Do not use a shared group queue for these cases; if a group is used at all, it must be a tightly scoped group of cleared HRBPs, not the whole department, and contractors excluded unless explicitly cleared.
Also review record-level visibility separately from task visibility: even if the task is individually assigned, if the underlying record's security lets the department group read it, the leak persists. Lock the record down to the assigned HRBP plus authorized roles.
2. What else must be checked beyond task assignment to ensure the case data itself is not exposed?
Read the worked answer
Task assignment controls who sees the task; it does not control who can read the record or its fields. Check:
- Record-level security. Confirm the case record's readers are limited to the assigned HRBP and authorized HR roles - not the department group. A task assigned to one person still exposes data if the record is group-readable.
- Field-level security. Grievance details and accommodation notes may need to be hidden even from some HR roles; apply field-level restrictions for the most sensitive attributes.
- Group membership hygiene. The two contractors in the department group are a risk if any residual group-based access remains. Audit membership and remove non-cleared users.
- Reports and dashboards. Aggregated or exported views can leak case content even when tasks are private. Verify report security and whether case-level detail appears in shared dashboards.
- Process history and audit. Ensure the audit trail and any process monitoring views don't surface case content to broad audiences.
- Notifications. Email/task notifications should not include sensitive detail in the body if they route to shared inboxes.
Recommendation: treat confidentiality as defense in depth - individual task assignment and record/field security and group cleanup and report/notification review. Test with a real non-assigned Finance user to confirm they see nothing.