Managers Seeing Other Divisions After an Org Restructure
Northwind Health runs Workday HCM for 14,300 workers across three regions. Managers see their direct and indirect reports through a role-based security group assigned to the Manager role on Supervisory Organization. In January the company collapsed 60 department-level supervisory orgs into 18 divisions. Since then, managers report seeing workers from other divisions in My Team prompts and in worker search results. Separately, four Americas Payroll Partners must view compensation for all US and Canadian workers but must not see EMEA or APAC. The security lead proposes adding those four to a user-based group granted unrestricted access to the Compensation domain, arguing that it is faster than reworking the org structure and safer because only four people are involved.
1. Managers are surfacing workers outside their own division. What do you investigate, in what order, and what is the most likely cause given how the restructure was done?
Read the worked answer
Investigate in this order - cheapest checks first.
- Read the role assignment, not the group. Open the role-based group's definition and confirm it is assigned to the Manager role on Supervisory Organization, not on Division or Company. A group assigned at a higher org type silently widens everyone's scope, and that is indistinguishable from a data problem when you only look at the symptom.
- Check whether the 60 old orgs were terminated or just re-parented. If the restructure was done as a re-parent, 18 division managers now legitimately sit at the top of merged hierarchies - expected behaviour, not a defect. If the old orgs were made inactive while workers still held future-dated moves, you get effective-dated overlap where a worker appears in two places.
- Check whether affected managers hold more than one Manager role. A manager who was also made manager of the division-level org for convenience now sees that whole org and its subordinates.
- Check for an additive second group. Security is a union of all group memberships. A manager who is also in a user-based HR or Recruiting group will see those workers regardless of how clean the role-based group is. Test this by removing nothing and instead running a group-membership report for one complaining manager.
- Verify with a test user, not with the admin account. Admin accounts bypass most of this and will tell you the configuration is fine when it isn't.
Most likely cause: the restructure changed the shape of the hierarchy so the role-based group now cascades to merged subordinate orgs, or a handful of managers were given a second Manager role at the division level. Both are org-model fixes; neither is fixed by editing the security group.
2. Evaluate the proposal to place the four Payroll Partners in a user-based group with unrestricted Compensation domain access. What would you build instead and why?
Read the worked answer
The proposal fails on three counts.
- It cannot restrict. Domain security is additive across all of a worker's group memberships. If these four already inherit Compensation access from a Payroll or HR Partner group, adding another unrestricted grant changes nothing; if they don't, you have granted company-wide compensation visibility to solve a two-country requirement.
- It doesn't scale or self-maintain. User-based groups are maintained by hand. The first transfer, leave, or replacement hire leaves stale access, and nothing in the system flags it.
- It's hard to defend in an audit. There is no membership logic to review - only a list someone edited.
Build instead: a segment-based group on the Compensation domain, segmented by Country (US, Canada) or by Location, depending on which segment type exists on the Compensation domain and which one is actually populated on the worker records. Attach the group to the Payroll Partner role, or join it to a role-based Payroll Partner group in an intersection group if only some Payroll Partners are in the Americas.
Before you commit: confirm the segment is derived from a field that is reliably maintained. If Canadian employees can sit on a US location record, a Location segment will over-grant and you have rebuilt the original problem with more steps. Test with a handful of edge-case workers - remote workers, dual jobs, and anyone on a leave of absence.
3. The company will not sign off until someone can show the fix works. What verification do you run, and what do you tell them about residual risk?
Read the worked answer
Verification, in order:
- Group membership report for the role-based group and the new segment-based group, filtered to the complaining divisions and to the four Payroll Partners. This shows intent, not effective access - necessary but not sufficient.
- A test user in Sandbox carrying a representative mix of role assignments (manager of one division, member of a Payroll Partner group). Sign in as that user and look at My Team, worker search, and a compensation report. This is the only check that shows effective access.
- A second test user who is deliberately a former manager whose reports were moved - the stale-assignment case that the restructure created.
- Re-run after the org cleanup, not before, so you are testing the final state.
Residual risk to state plainly:
- Security is additive, so access you did not intend can still arrive through a group nobody reviewed. Periodic membership review is the control, not the initial build.
- Segment-based access is only as good as the segment data. Any worker whose country or location is wrong gets the wrong visibility.
- Neither test proves anything about Production if Sandbox has drifted. Confirm the Sandbox refresh date before claiming the test is meaningful.