Entra ID Automation #3 Group Design: Dynamic Groups, Group-Based Licensing, Access Packages

The last part ended with “user automation’s job is putting people in the right groups.” This part is the group side of that. Design groups well and licenses, app access, and permissions flow along the group structure by themselves; design them badly and you invent a new form of toil — hand-managing hundreds of groups.

Two kinds of groups: security groups and Microsoft 365 groups #

Entra ID groups come in two major kinds.

For automation design the criterion is simple: access control → security group; collaboration space → M365 group. Membership rules differ too: security groups can contain users, devices, service principals, and other security groups (nesting), while M365 group members can only be users.

Via Graph, create with POST /groups and add members with POST /groups/{id}/members/$ref. But before writing that member-adding code, first ask whether the two mechanisms below can eliminate the code entirely.

Dynamic groups: membership by rule, not by code #

A dynamic membership group has no human-managed member list. Define an attribute-based rule and Entra ID adds and removes matching users automatically.

// Full-time employees in Engineering
(user.department -eq "Engineering") and (user.employeeType -eq "Employee")

// Members only, active accounts
(user.userType -eq "Member") and (user.accountEnabled -eq true)

This is where part 2’s insistence on attribute standardization pays off. If department holds both “Engineering” and “engineering dept,” the dynamic group catches half. A dynamic group’s quality is the quality of the attribute data, not the rule.

Three operational facts to know:

• Licensing: Entra ID P1 is required for each unique member of dynamic groups.
• Limits and membership: a tenant tops out at 15,000 dynamic groups, and only users and devices can be members.
• Latency: membership recomputation is not instant. There is lag between an attribute change and its reflection, so flows that need “this person in, right now” belong to static groups plus the API.

Summarized: attribute-expressible affiliation (department, job family, location) → dynamic groups; approval-gated optional access → static groups (or access packages, below); immediacy-critical operations only → direct API.

Group-based licensing: entry is assignment, exit is reclamation #

Attaching licenses to a group is configured with Graph’s POST /groups/{id}/assignLicense (or the admin center). From then on, membership is license state — joining assigns, leaving reclaims.

Combined with dynamic groups it becomes powerful. Attach developer tooling licenses to the “Engineering department” dynamic group and a department transfer (HR → attribute change → dynamic recomputation → license move) completes without a human hand. JML’s Mover flow is this combination’s biggest beneficiary.

The operational companion is assignment error monitoring. When license stock runs out or service plans conflict, group assignment can fail for specific users and stay failed. A script that periodically reads the group’s license error state and alerts is the standard sidekick to this setup.

Role-assignable groups: the admin-privilege boundary #

To attach Entra ID admin roles to a group, an ordinary group will not do — it must be a role-assignable group, created with isAssignableToRole: true. These groups are treated differently: dynamic membership is not allowed, and member management is restricted to higher-privileged roles. The design intent is blocking the path where a single attribute change confers admin rights. This group type returns in part 5, combined with PIM, as the material for “joining the group makes you an admin candidate; activation turns the privilege on.”

Access packages: productized self-service access requests #

The last manual chore that group design alone cannot remove is the “access request ticket” — I joined project X, please add me to these three groups, that SharePoint site, and two apps. Entra’s entitlement management productizes exactly this. It is a Governance-license feature.

• An access package bundles groups, apps, and site access into one requestable unit.
• Request → approval flow (manager or designated approvers) → automatic grant → expiry and renewal (automatic reclamation on expiry, extension requests) are all product features.
• It shines for external collaborators (guests): package expiry is guest-access termination, so “the contractor account that outlived the project” disappears structurally.

The IT-team payoff is clear: access tickets become self-service requests, and not just granting but reclamation becomes automatic. This is identity management’s version of the self-service stage from SRE in Practice #6.

Summary #

• Access control uses security groups; collaboration uses M365 groups. Before writing member-management code, check whether dynamic groups or access packages eliminate it.
• Dynamic groups automate membership from attribute rules (P1, users and devices only, with propagation lag). Their quality is decided by attribute data, not rules.
• Group-based licensing makes entry = assignment and exit = reclamation; combined with dynamic groups, department moves run unattended. Pair it with assignment-error monitoring.
• Admin roles go only through role-assignable groups — a separate security boundary where dynamic membership is prohibited.
• Optional and time-boxed access becomes self-service through access packages; the automatic reclamation is worth more than the granting.
• Next: the sign-in-moment defense line — managing Conditional Access policy as code.