Somebody still has to say
what this access is.
Connecting a system gives you thousands of groups with names like GG_SAP_FI_DISP_P. Nothing automatic turns that into something a manager can approve. Three wizards — application, entitlement, role — put a recognisable name, an owner and a purpose on the ones that matter, and a retirement plan on the ones that no longer do.
Applications
Put the application in front, and the raw group steps back.
An application is the thing your business already talks about — Confluence, SAP, GitHub Enterprise. Onboarding one means naming the directory groups that actually grant it, and from that moment the application is what people request. The raw group stops being individually requestable, because asking for it directly would walk straight past the owner, the approval chain and the review you just set up.
- One helper does the fronting, so every path — the wizard, an owner accepting a catalogue change, app mining — behaves the same
- Fully reversible: unfronting hands requestability back, unless a retirement was the thing that took it away
- Deleting an application unfronts its groups, so nothing is left orphaned behind a tag pointing at something that no longer exists
- If there is nothing to request in its place, we tag but never demote — and say so loudly. Demoting a group with no app role behind it leaves the business with no route at all
Entitlements
An owner before it exists, not an ownership drive afterwards.
Onboarding an entitlement is where a permission gets a name a person recognises, a purpose, a risk level and somebody accountable for it. The submit gate refuses without an owner — in the service, not just as a disabled button — because "we'll assign owners later" is how an estate ends up with a coverage figure nobody believes.
- Application, entitlement and role are three wizards with one shape — the same submit, approve and fulfil path, not three lookalike flows that drift
- Requestability cascades from system to application to type to the entitlement itself, and the most restrictive level wins. Closing a system shut cannot be undone one level down
- A duplicate check and a naming convention run before you submit, not as a clean-up project a year in
- An approved request can create the entitlement in the target, or adopt one that already exists — both leave the same governed record behind
Retirement
Turning something off is a plan, not a delete.
Applications, entitlements and roles leave the catalogue the same way: a plan with an explicit approval and a grace window. Thirty days by default, tenant-configurable. While it runs, the thing is visible and marked, new requests are blocked, and the people who still hold it have time to move. When the window closes, a sweep revokes the remainder and retires it.
- The same plan covers all three: an application, an entitlement, a role
- Separately, three detectors can flag something as "stop granting this" — a group that vanished from its source, one nobody holds, one pointing at a context that no longer exists. Those are flags with no clock and no revoke. They tell you; they do not act
The retirement path
Cancelling a retirement restores the exact stage the thing was in before — captured when the plan was made. An earlier version reset everything to "active", which once left a live role with 482 holders displaying as a draft. Putting things back is only trustworthy if it puts back what was actually there.
Related
Bring one system, and see what it would take to name it.
A 30-minute kickoff connects your HR feed and one system — working POC the same day.
Bring your HR feed plus one system you trust us to read — that is all the kickoff needs. No NDA, no second call with a sales engineer, no procurement form.