Requestable catalog
Bundle entitlements from an application into something a non-technical user can understand and ask for.
Self-service access, governed by policy
A self-service catalog with configurable approval policies and an approval queue — so access is requested, approved and recorded in one flow.
When getting access means emailing someone who knows someone, the decision is undocumented and the outcome is inconsistent. Access requests give users a catalog of what they can ask for, route each request through the approval policy that applies to it, and provision the result automatically once approved — with the whole chain recorded.
How Access Requests works
The mechanics behind the capability — what the platform does, and where it does it.
Configurable approval policies
Route by application owner, line manager or a defined approver, with single or multi-step chains as the risk warrants.
Segregation of duties at request time
Toxic combinations are evaluated before the grant, so conflicting access is prevented rather than discovered later.
Approval queue
Approvers see what is waiting on them in one place, which is what keeps requests moving.
What it changes
Who feels the difference once Access Requests is in place, and how.
End users
Access in minutes, not days
A governed path is faster than an informal one, which is what stops people routing around it.
Audit
Decisions are documented
Every grant has a requester, an approver and a justification attached, which is exactly what an auditor asks for.
Application owners
Owners decide their own systems
Approval sits with the people who understand the consequences, rather than with a central team guessing.
Governance
Conflicts never get granted
Checking separation of duties before approval avoids the far harder job of unwinding it afterwards.
See Access Requests in context
It works because the other capabilities share the same identity fabric. The quickest way to judge that is to watch it run against your own use cases.