Updated recently
Last updated:
Quick Answer: a SailPoint identity request is the formal object that carries an access change from request to delivery: a user (or process) submits a request for a role or entitlement, IIQ runs it through approval workflows, policy checks and a provisioning plan, then executes against target systems and tracks the result to completion. Understanding this lifecycle matters because every “access request is stuck” ticket is a lifecycle stage you have not learned to inspect yet.
The Lifecycle Stage by Stage
| Stage | What happens | What can go wrong |
|---|---|---|
| 1. Submission | Request raised via quicklink or API; IIQ snapshots requested items | Quicklink scope misconfigured; item not requestable |
| 2. Policy validation | SoD and policy scans evaluate the request before approvals | Violations block requests that “worked last week” — policy data changed |
| 3. Approval | Approval workflow routes to manager/role owner/app owner | Missing approver mapping stalls the request in an empty queue |
| 4. Provisioning plan generation | Approved items become account operations per provisioning policies | Policy/attribute mapping errors produce malformed plans |
| 5. Execution | Provisioner applies the plan via the target connector (IQService for AD) | Target outages, connector failures, IQService queues |
| 6. Verification & completion | Results recorded; identity refreshed; request marked complete/failed | “Completed” but target state wrong — verification config too weak |
What the Object Model Looks Like
The IdentityRequest is the parent object holding provisioning transactions, which hold per-item provisioning plans. The states move through stages you can query — and interviewers love asking what distinguishes a failed transaction from an unfinished one (answer: failure recorded vs workflow still open). For how plans are structured internally, see the IIQ workflow examples.
A Debugging Walkthrough You Can Reuse
A request shows “Pending” for two days. The disciplined diagnosis:
- Find the request: identity request list filtered by identity and date. Note the exact state, not the user’s paraphrase of it.
- Check approvals first: most “stuck” requests are approval-stage orphans — an approver left the company, and the workflow has no assignment rule for that role.
- Then check the transactions: if approvals completed, open the provisioning transaction. Per-item status tells you whether the plan generated at all.
- Then check the target: plan generated, execution failed — connector logs, IQService queue (for AD), target availability.
- Fix at the cause: reassign the approval, repair the policy mapping, or re-run the failed plan item — never “just resubmit” over a systemic issue.
In one banking project, a third of “stuck” requests traced to one empty approver list after a reorganisation. No code change was needed — an assignment rule update plus a one-time reassignment of queued requests. The lesson: lifecycle problems are usually configuration archaeology, not development.
Request Scopes and Quicklinks: The Design Layer
What users may request is governed by quicklink configuration, request scopes and role/entitlement requestability. Getting this layer right pre-empts most tickets: requestable items must have owners who actually exist, scopes must reflect organisational reality, and policy scans must run before approval (cheaper) rather than after (embarrassing). The policy model guide covers the enforcement side.
Designing Requests That Age Well
Request design decisions outlive the people who made them, so a few conventions pay compounding interest. Name quicklinks by user intent, not system intent (“Request Mailbox Access”, not “QKL-342”), because the catalogue is either self-documenting or it is a ticket generator. Keep scopes tight and reviewed — a scope that has grown unchecked for two years is how someone requests production access on three systems in one cart. Map approval assignments to roles or attributes rather than named individuals wherever the client’s model allows, because named-approver configurations break silently on every attrition wave and produce exactly the “stuck in pending” tickets that erode trust in self-service. And version your requestability decisions: when finance asks why the analysis entitlement became requestable last March, an audit note answers in minutes and an archaeology project answers in weeks. The design layer is where governance either becomes real or becomes wallpaper.
Approval Design Patterns Worth Knowing
Three patterns cover most real estates. Manager-first is the default and the simplest to defend, but it presumes manager data is clean — tie it to a data-quality metric or it quietly rots. Owner-based approval routes decisions to application or entitlement owners: better judgements, at the cost of more configuration and the occasional orphaned owner. Role-based approval (approver roles populated by rule) scales best in large organisations and needs the most careful design, because a rule bug mis-routes thousands of decisions at once. Many clients run a hybrid: manager for low-risk, owner for sensitive, security-team escalation for privileged — and that hybrid is also the pattern to describe in interviews when asked how you would design approvals, because it shows the trade-off thinking the question is really probing.
Metrics Worth Tracking
Request pipelines drift without measurement, and four numbers catch the drift early. Cycle time by stage (submission-to-approval, approval-to-provision, provision-to-verified) — because “requests are slow” is unfixable while “approvals sit 2.3 days” is a meeting with an outcome. Failure rate by target system — one target contributing most failures names the integration that needs attention before users do. Rework rate — the share of requests re-raised after rejection, which measures how well requestable catalogues match reality rather than how naughty users are. And approver load — the distribution of decisions across approvers, which surfaces single points of failure long before leave season does. Publish these monthly to whoever owns the process; the IIQ roadmap places this reporting literacy in the admin-to-lead transition, where it is honestly the differentiating skill.
Training Resources
The SailPoint IdentityIQ Certification Training includes a full request-to-provisioning lab where you build, break and repair this lifecycle yourself. For the wider context, see the IIQ roadmap, and the IAM training track for request management beyond SailPoint.
FAQ
What is an identity request in SailPoint IIQ?
The tracking object for an access change: who requested what, approvals, policy results, provisioning outcome. It is the audit trail for self-service access — and the first place to look when someone says their access is “stuck”. Every role in an IIQ team eventually debugs from this object, which is why interviews keep returning to it.
Why is my SailPoint access request stuck in pending?
The three usual causes in order: an approval step with a missing or departed approver, a provisioning failure at the target, or a policy violation flag awaiting manual handling. Inspect the identity request state, then the transaction, then the target logs — timestamps across those three layers usually name the guilty stage before you finish reading.
Can provisioning be automatic without approvals in IIQ?
Yes — low-risk items can skip human approval where policy permits. Most organisations still keep an approval step for anything privileged, both for audit evidence and for SoD enforcement — automation without an evidence trail satisfies nobody’s auditor.
What is the difference between an identity request and a provisioning plan?
The request is the business-level object (who asked for what, approvals); the plan is the technical instruction set (create this account, add this group). One request can produce multiple plans across multiple targets, which is why a “simple” request failing on one system still needs the full debug path.
How do I re-run a failed provisioning request?
Fix the underlying cause first (target availability, mapping, connector), then retry the failed transaction items from the request — blind resubmission just recreates the failure and hides the root cause from your trend metrics. If the same target fails three weeks running, escalate the pattern — repeated patches are how request pipelines rot.
