Request flow
How a self-service access request travels from submission to fulfillment.
A user requests access, the request is routed for approval, policy is checked, and on approval provisioning fulfills it.
- Purpose: let users request access and have it governed and fulfilled
- Trigger: A user submitting an access request
- Outcome: Requested access is approved and provisioned, or denied
- Where it fits in the SailPoint architecture
The access request flow is the self-service journey by which a user asks for access and has it governed and fulfilled. It is the most visible part of IdentityIQ for ordinary end users and the mechanism that turns access from an opaque back-office process into a transparent, auditable one.
What triggers the flow
A user (or someone requesting on their behalf) opens the access request catalogue and selects roles, entitlements or applications to request. Requesting for others, a manager onboarding a team, is a common variant.
Step by step
- 1. Submit. The requester chooses items from the catalogue and submits, optionally with a business justification.
- 2. Routing. The request is routed to the appropriate approvers, defined by ownership, role owner, resource owner, manager, or a workflow.
- 3. Policy check. Separation-of-duties and other policies are evaluated; a conflict may block the request or require an explicit exception approval.
- 4. Approval. Approvers approve, reject or reassign. Multi-level approval chains are common for sensitive access.
- 5. Fulfilment. On approval, the provisioning flow executes the change on the target system (automatically or via a manual work item).
- 6. Notification and audit. The requester is told the outcome, and the full request-to-fulfilment history is logged.
What makes a good request experience
The catalogue is where governance meets usability. A well-designed catalogue presents business-meaningful items, roles and clearly-described entitlements, rather than cryptic technical group names, so users request what they actually need and approvers understand what they are approving. Poor descriptions here undermine every downstream control.
Requests and least privilege
Access requests are the controlled alternative to invisible, direct grants in target systems. Because every requested grant is justified, approved and logged, the request flow both satisfies auditors and supports least privilege, access arrives through a governed door rather than accumulating in the shadows.
Common pitfalls
- A catalogue full of technical jargon that users and approvers cannot interpret.
- Approval fatigue, so many requests that approvers rubber-stamp; scope approvals to what genuinely needs review.
- No SoD check at request time, letting toxic combinations in that must be caught later.