Permissions don't get assigned to people. They get assigned to groups, because nobody has time to configure access one person at a time, and because grouping people is just easier when the people are already grouped for you. Your organization is already divided into departments, regions, teams. So that's what the groups become. Sales gets a group. West Region gets a group. The AP team gets a group.
The problem is that all those groups get put in an identity provider where they can be used by any application: the same directory backing your CRM, your file shares, your payroll system, everything else in the building. That's efficient right up until one of those applications needs the group to mean something the others don't, like a contractor who needs access to one app and nothing else, that membership in "Sales - West Region" happens to unlock. Eventually there's a reason for the membership to diverge, and because the group is shared, it can't diverge for just one application without changing what it means for all the others too.
There's a fix for this, and it's a little counterintuitive: not to stop copying the org chart, but to give your application an org chart of its own. One that isn't borrowed from HR, or Active Directory, or wherever else the "official" version lives, and doesn't have to be re-copied by hand every time something changes. Before that makes sense, it's worth seeing exactly why the copying goes wrong in the first place.
Being shared is part of why nobody fixes it. If three other applications are reading the same group, changing risks breaking something you don't own, so instead of being adjusted, it just gets left alone. What actually happens is a new group gets created, with a name for whatever specific need just came up. That new group is where the trouble really starts, because nobody owns keeping it current either.
The group matched the org chart on the day someone created it. It was accurate then. But the org didn't stop moving. People got promoted, teams got reshuffled, whole departments got renamed or folded into other ones, and nothing moved the group along with it. You don't have a live copy of your org chart sitting in your permissions system. You have a photograph of it, taken once, that everyone downstream is still treating as current.
Photographs don't age gracefully. Somewhere in your access control system right now there's almost certainly a group called something like "Temp - Q3 Reorg Access (DELETE AFTER)." Someone made it years ago to cover a reorg that was supposed to be temporary. Someone else, at the time, even flagged it for deletion, hence the name, a note-to-self that never got acted on. It's probably still active. People probably still get added to it, quietly, because it's close enough to what they need and nobody's quite sure what removing it would break. The fix isn't a better process for updating the photo. Taking the picture more often or being more disciplined about deleting groups with "DELETE AFTER" in the name won't solve the problem.
When people get organized into groups or trees, there is a purpose, and that reason should be specific and documented. The organizational tree in Active Directory and the chart managed by HR answer different questions. Active Directory is scoped to what can log into what, across the whole enterprise. HR's chart is scoped to who reports to whom. Neither one was built to answer this application's questions: who can approve an invoice, who can see a dashboard, who can edit a record. The tree your app needs might look a lot like the HR chart in most places. It doesn't have to match it exactly. A matrixed employee, a cross-functional lead, a contractor who isn't even in HR's system yet very much needs scoped access. These are exactly the places where the "official" org chart stops answering the application's question too.
If your application modeled the organization, with its own tree, tenants and groups and roles, purpose-built for its own authorization decisions, then the maintenance of it wouldn't be a negotiation caused by conflicting purposes. Being on the tree would be the reason for access. Move someone to a new spot in the org, and their access moves with them, automatically, because there's only one org chart to update, not two.
That's a bigger claim than it sounds like, so we wrote a companion describing exactly how it works: how an org tree turns into identity claims, and how those claims plug into an ASP.NET Core authorization policy. If you want the mechanics, "Org Tree Claims and ASP.NET Core Policies: Technical Reference" has the full breakdown, question-by-question.