Why manual access drifts
When someone joins, a manager raises a ticket, IT adds them to a handful of groups, and everyone moves on. When the same person changes team, the new access gets added and the old access rarely gets removed. After a few moves, a long-serving member of staff can open finance, HR and project sites they have not needed for years. Nobody decided that. It accumulated.
Dynamic groups reverse the logic. Instead of a person adding members, a rule evaluates attributes on each user account, such as department, job title, office location or company name, and Entra ID maintains the membership. Change the attribute and the membership follows. That is the whole model, and it is only as good as the data behind it.
This guide covers the order we usually work in: fix the data, design a small set of groups, then deal with joiners, movers and leavers in turn, with SharePoint Online as the main place the groups are used.
Fix the source of truth first
Before writing a single rule, decide where each attribute comes from and who is allowed to change it. In most organisations the answer should be HR. If you run Active Directory with Entra Connect or Cloud Sync, attributes usually flow from the HR system into on-premises AD and then into Entra ID. If you are cloud-only, Entra ID supports inbound provisioning from some HR systems, and an API-driven route for others. Either way, the HR record should be the master, and nobody outside HR and IT should be able to edit the attributes your rules depend on.
Then look at the values. Free-text department fields are the usual problem: Finance, Finance Team, Fin and finance all turn up in the same tenant, and a rule matching one misses the rest. Agree a controlled list of values with HR, clean up the existing accounts, and get HR to enforce the list when records are created or changed. This is dull work and it is most of the project.
Agree the following with HR before any rule is written:
- Which attribute identifies the team or function, usually department.
- Which attribute identifies the legal entity, if you have more than one, usually companyName.
- Which attribute separates employees, contractors, volunteers and other worker types, such as employeeType.
- Which attribute holds a stable unique identifier, such as employeeId, for matching and reporting.
- Who in HR enters each value, and how soon after a change is agreed.
Design groups in layers
Resist building one dynamic group per SharePoint site. A more manageable pattern is a small set of building-block groups based on stable facts about a person: everyone employed, everyone in a department, everyone in an entity, everyone of a given worker type. Sites, Teams and applications are then granted to those groups, and the number of rules stays small enough to understand.
A department rule might read: (user.department -eq "Finance") -and (user.employeeType -eq "Employee") -and (user.accountEnabled -eq true). The accountEnabled clause matters. It means a disabled account drops out of every group built this way, which gives you a leaver control at no extra effort.
Use a naming convention that says what the group is and that it is dynamic, for example a DYN prefix. Otherwise someone will try to add a member by hand and wonder why they cannot. A group is either dynamic or assigned, never both, so genuine exceptions need a separate assigned group with an owner.
Dynamic membership needs a premium Entra ID licence for the users in scope. Licensing changes, so confirm the current requirements with Microsoft before you design around it.
Joiners: access on day one
A joiner becomes a member of the right groups once their account exists with the right attributes. That puts HR on the critical path: if the new starter's record is created late or with the wrong department, the access is wrong too. Agree a lead time with HR so accounts are created before the start date, and decide whether the account stays disabled until day one. If it does, remember that accountEnabled rules will not add the person until it is enabled.
Membership processing is not instant. Entra ID evaluates rules in the background, and after a bulk change in a large tenant it can take a while. SharePoint and Teams also take time to reflect new group membership. Do not promise access to the minute. Promise it by the start time, and enable accounts early enough to absorb the delay.
Use group-based licensing on the same groups, or on an all-staff dynamic group, so licences arrive with the account rather than as a separate ticket. The same applies to default apps, distribution lists and device enrolment policies that can target groups.
Movers: the hardest case
Movers are where dynamic groups earn their keep and where they cause the most surprise. When HR changes someone's department, they leave the old department's groups and join the new ones at the next evaluation. Old access goes as new access arrives, which is the point. It also means a person can lose access to work they are still handing over.
Handle this with process, not exceptions. Agree with HR that the attribute change is made on the effective date of the move, not the date it is agreed. Where a handover period is genuinely needed, give temporary access through an assigned group with a named owner and an end date, and review it. Avoid editing a dynamic rule to exclude one person. Those exclusions outlive the reason for them.
Check what else hangs off the attribute. If department also drives a distribution list, a Team, an app role and a licence, one HR change moves all of them at once. That is usually what you want, but the service desk should know, so they do not treat it as a fault and start adding people back by hand.
Leavers: disable first, then tidy
For leavers, the order matters. On the leaving date, disable the account and revoke the user's sessions so existing sign-ins stop working. Because your rules include accountEnabled, the user then drops out of the dynamic groups, which removes SharePoint and application access granted through them.
Removing group membership is not the whole job. Files shared directly with the person, content they own, their OneDrive, their mailbox, and any application that does not use Entra ID for sign-in all need their own steps. Decide in advance who receives OneDrive content, what happens to the mailbox, and how long the account stays disabled before deletion. Your retention schedule should drive those answers, not convenience.
If HR records the leaving date in advance, schedule the disable rather than relying on someone remembering on the day. Entra ID Governance includes lifecycle workflows built for this, with their own licensing. A scheduled script or automation runbook working from the HR feed is the alternative. Whichever you choose, keep a manual route for urgent, unplanned departures.
Using the groups in SharePoint Online
Grant SharePoint access to dynamic security groups, not to individuals. Add them to a site's Members or Visitors SharePoint groups so the rule decides who gets in. For a group-connected site or a Team, you can instead make the Microsoft 365 group itself dynamic, but its owners can then no longer add members, and that applies to the Team too. Tell site owners before you change it, and do not do it for teams that regularly bring in people from outside the department.
Avoid breaking permission inheritance on folders and files to give individuals access. Every unique permission is something the dynamic groups cannot fix later. If a site genuinely needs two different audiences, it is often two sites.
Keep the Everyone except external users claim and organisation-wide sharing links away from sensitive sites. They bypass the group model entirely, and no amount of careful rule writing will undo them.
Ownership, testing and monitoring
Write down who owns what. HR owns the attribute values and their accuracy. IT owns the rules, group naming, licensing and the leaver automation. Site owners decide which groups get access to their site. Information governance owns what happens to a leaver's data. Without that split, every wrong membership becomes an IT ticket, when the fix is usually an HR record.
Build the checks into the routine:
- Validate each new rule against known users in the Entra admin centre before saving it.
- Create new groups and check their membership before granting them access to anything.
- Report monthly on accounts with blank or non-standard values in the attributes your rules use.
- Restrict who can edit dynamic rules, and review rule changes in the audit log.
- Pilot with one department before converting existing assigned groups.
Switching over without disruption
We usually start with an all-staff group and two or three departments, build the dynamic groups alongside the existing manual ones, and compare membership side by side. Resolve every difference before moving access across. The differences are almost always data problems, and it is far better to find them in a comparison report than through a phone call from someone who cannot open their files.
Once a department is switched, remove the old assigned group from sites rather than leaving both in place. Two routes into the same site is how manual access creeps back.