A group built for one acquisition, still open three years later
I found the group during a routine access recertification for a mid-size logistics company: ACQ - Meridian Freight Integration. Meridian was a freight brokerage the company bought in early 2023. The integration team stood up a security group that gave about ten people across both companies visibility into compensation data and the combined org hierarchy while payroll and reporting structures got reconciled. That project closed in September 2023. When I pulled the membership report in the spring of 2026, fourteen people still held that group, and only two of them had been on the original integration team.
Nobody had removed the access because nobody owned removing it. The HRIS team that inherited the tenant after the integration wrapped didn't build the group and didn't want to touch it without knowing what would break. Two of the fourteen people had left the acquisition work entirely and moved into unrelated roles, but the group followed them anyway, because Workday security groups attach to a person, not a job, unless someone actively reassigns them. That's the pattern behind most sprawl I've seen: access outlives the reason it was granted, and it outlives it by years.
How forty groups pile up in three years
The review that turned up the Meridian group also turned up thirty-nine others, and the HRIS director couldn't map more than half of them to a current job function without opening each one and reading through its domain assignments one at a time. That's a normal outcome of three years of small decisions, not one bad decision. A manager needs a contractor to see comp ranges for a single open requisition, and rather than extending the existing HR Partner group and risking a change that touches everyone already in it, someone stands up a narrow one-off group scoped to that single case. It solves the problem in an afternoon and it never gets revisited.
The other common path is the copy. Someone opens an existing group, HR Partner, North America, hits copy to avoid rebuilding domain assignments from scratch, and changes one permission for one person's request, usually adding a compensation change domain a specific team lead needed for a single cycle. The new group gets a name like HR Partner, North America v2, and no one links it back to the original in any system of record. Eighteen months later the original group gets updated for a policy change, the copy doesn't, and now two groups that look like they do the same thing have quietly diverged.
Multiply that by a couple of reorganizations and one acquisition, and a tenant that started with twelve clean role-based groups ends up with forty, a dozen of which have five or fewer members and a comment field that's either blank or says something like temporary access, added 2022, the same kind of drift covered in comp cycle configuration drift.
Finding the groups that are really duplicates
Start with membership, not permissions. Pull a report on the Security Group business object with a related field for assigned users, export every group's roster to a spreadsheet, and compare rosters pairwise. You're looking for groups where seventy percent or more of the membership overlaps. In the logistics company's tenant, HR Partner, North America and HR Partner, North America v2 had eleven of thirteen members in common. That overlap alone doesn't prove they're duplicates, but it tells you exactly where to look next.
Permission overlap is the check people skip. Two groups can share almost no members and still grant identical access if they show up together on every domain security policy and business process security policy in the tenant. Run the report that lists security groups by domain, one domain at a time for functional areas like Compensation and Absence Management, and flag any pair that appears together on every single policy row. If group A and group B are never assigned to a domain independently of each other, one of them is redundant no matter what their membership lists say.
Score every pair on both dimensions, membership overlap and domain overlap, and work the highest-scoring pairs first. Before merging anything, confirm with the manager who actually requested each group, not just the HRIS team maintaining the tenant. A group with low membership overlap but identical domain coverage might still need to stay separate if it routes through a business process step the other doesn't touch.
Tracing a mystery group back to why it exists
Before you deactivate anything, you need lineage. Open the security group definition and check the Created On and Created By fields. That gives you a name and a date, and a date is usually enough to cross-reference against a change ticket or an old project plan. In the Meridian case, the created date lined up exactly with the week the integration kickoff happened, which made the source easy to confirm even though the comment field on the group itself had never been filled in.
When the comment field is blank, which is most of the time, the domain and business process references do the talking. Pull every domain and every business process security policy that currently references the group. A group with zero active references anywhere in the tenant is a strong deletion candidate on its own. A group that does show up on active policies needs a second check: whether another group already covers that same access. If another group already provides identical coverage, the mystery group is redundant even though it's technically still doing something.
Then talk to the people still in it. I called four of the fourteen people still carrying the Meridian group and asked what they used the access for. Three said they didn't know they had it. The fourth, a finance manager, was still pulling a monthly headcount reconciliation across both entities and genuinely needed it, which became the one case we kept open on purpose instead of by accident.
What happens to each flagged group
Every flagged group ends up in one of three buckets. Merge candidates get their members reassigned to the surviving group and then get deactivated, since Workday won't let you hard-delete a security group with any assignment history. Groups tied to a live business process step you're not ready to touch get frozen with a documented revisit date, usually the next quarterly review, rather than left open indefinitely by default. Everything else, the groups with no current references and no one still using them, gets its membership stripped and the group itself deactivated.
Test each merge in a sandbox tenant before touching production. Run the affected business process end to end with a test user carrying only the surviving group's access, and confirm approvals still route the way they did before. The failure mode people worry about, an approval step silently losing its approver pool, is exactly the kind of thing a five-minute sandbox test catches and a production surprise doesn't.
A review cadence that actually holds
The audit fixes the backlog. It doesn't stop the next one from forming unless someone owns the calendar. Assign each functional domain, Compensation and Absence Management for instance, to a named business partner, not a shared HRIS inbox, and put security group review on the same quarterly cycle as your SOX access recertification instead of treating it as a separate, lower-priority exercise that only happens when a review forces it. Some organizations fold this into a small center of excellence rather than spreading ownership across every business partner, and either model works as long as someone specific is on the hook.
Fix the intake, too. Any group created for a one-off project or a time-bound initiative like an acquisition should carry a sunset date and a named sponsor on the request ticket before it gets built, the same discipline you'd expect from an ERP master data governance program or from the intake habits covered in Workday Extend governance guidance. A group with no expiration date is a group that will still be granting access to someone's old job three years from now.
Pull the list right now of every security group in your tenant with zero domain or business process policy references, and put a name against each one before your next quarterly cycle. If nobody can produce a business reason within thirty days, deactivate it. Groups with no sponsor and no expiration date belong on a retirement list the same way any other unused configuration does. Don't schedule a follow-up meeting to think about it further, that follow-up meeting is exactly how you end up with forty groups again in three years.
