Entra ID governance sandbox

The question

Access packages look simple in the documentation: define a catalog, attach some resources, set an approval flow. The complexity shows up later — when an approver is out of office, when an assignment expires mid-project, when two catalogs need to share a resource without duplicating it. Most guidance stops before that point.

So: how does an access package catalog actually behave once assignments start expiring, approvals start queuing, and the directory stops being empty?

Setup

The sandbox models a small organization's catalog structure — a handful of resource groups, a few access packages with different approval chains, and a mix of time-limited and standing assignments. Everything is provisioned and torn down through the Microsoft Graph PowerShell SDK rather than the admin center, so the whole catalog structure is reproducible from a script rather than a set of manual clicks someone has to remember.

What gets measured

• Time from request to access, across single-approver and multi-approver chains.
• What actually happens to an assignment at expiry — whether access drops cleanly or leaves a stale group membership behind.
• Behavior when an approver is removed from the directory mid-cycle.
• How cleanly a catalog structure can be exported, audited, and rebuilt from script.

Notes so far

• Expiry is the part every walkthrough skips, and it's where most of the actual design decisions live — what happens to the assignment, the group, and any downstream access it granted.
• A catalog that only works when defined by hand doesn't survive a rebuild. Scripting the whole structure from the start makes disaster recovery a non-event instead of a project.

Reproducing it

The catalog structure and provisioning scripts use only documented Graph endpoints and the public Microsoft Graph PowerShell SDK — nothing here depends on anything specific to this tenant.