Request flow
Quick answer
A user requests access, the request is routed for approval, policy is checked, and on approval provisioning fulfills it.
Key takeaways
- 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.
Want to learn this properly?
Our live, instructor-led SailPoint Training covers this hands-on, with real projects and a certification path.
Check your understanding
What triggers the request flow?
- A. Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.
- B. Requested access is approved and provisioned, or denied
- C. A user submitting an access request
Show answer
C. A user submitting an access request
A user submitting an access request
What is the outcome of the request flow?
- A. A user submitting an access request
- B. Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.
- C. Requested access is approved and provisioned, or denied
Show answer
C. Requested access is approved and provisioned, or denied
Requested access is approved and provisioned, or denied
Where does this flow run?
- A. Requested access is approved and provisioned, or denied
- B. A user submitting an access request
- C. Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.
Show answer
C. Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.
Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.