Iiq Request Status Decoder
Turns IdentityIQ's raw completion/execution status pair into a plain-English answer for the help desk agent staring at a "Completed Pending Verification / Terminated" request and a confused user.
IIQ Request Status Decoder
Turns IdentityIQ's raw completion/execution status pair into a plain-English answer for the help desk agent staring at a "Completed Pending Verification / Terminated" request and a confused user.
Date: 2026-08-31 Type: App Theme: UX + Detect Platform: SailPoint IdentityIQ Status: Idea
What it is
A single-page, read-only app that loads a list of IdentityRequest records and decodes each one into four buckets a non-engineer can act on: Done, In Progress, False Failure (no action), and Needs Escalation. Click a request and you get the raw completionStatus/executionStatus/currentStep fields side by side with a sentence that says what actually happened and what to do next.
Who it serves
Tier 1 / Tier 2 help desk agents fielding "where's my access?" tickets, plus the end users who filed them. The native IIQ "Track My Access Requests" quicklink already shows these requests. This app sits on the same data and answers the question that page doesn't: is this a real problem, or is IIQ still catching up with itself?
The IIQ pain it addresses
IIQ's Lifecycle Manager tracks every access request as an IdentityRequest with two status fields that don't always agree. completionStatus covers the approval/provisioning path (Pending, Approved, Rejected, Completed, Cancelled, or "Completed Pending Verification"). executionStatus covers the workflow engine underneath it (Executing, Verifying, Terminated, Completed). A request can sit at "Completed Pending Verification" / "Verifying" for a while, and that's normal: IIQ is waiting for an aggregation or targeted read-back to confirm the entitlement actually landed on the target system.
The problem shows up when that verification window closes. A SailPoint community thread from 2026 documents a request whose role assignment succeeded on the target system, but the request stayed "Incomplete" with a timeout error, because the aggregation read-back never matched what was provisioned before maxVerificationDays ran out on the Identity Request Maintenance task. From the outside, that looks identical to a genuine provisioning failure: same "Terminated" execution status, same stuck request in the queue. A help desk agent can't tell the two apart from the native status fields alone, so both get escalated, and both waste an engineer's time chasing something that, in roughly half the cases, already worked.
How it works
Two panels. The left panel lists every request with a decoded status badge instead of the raw IIQ string, filterable by the four buckets and searchable by request ID, requester, requestee, description, or application. The right panel shows the selected request's decoded explanation in a colored banner (blue for in-progress, green for done, amber for false-failure, red for escalate), a one-line suggested action, and a raw-fields table underneath so an agent who wants the actual IIQ values can still see them.
The decoding logic lives in one place in script.js. The interesting branch: when completionStatus is "Completed Pending Verification" and executionStatus is "Terminated," the app checks a simulated entitlementConfirmedOnTarget flag (standing in for what a real deployment would get from a Link/aggregation cross-check) and splits the same raw status into "access is actually there, verification just timed out" versus "access really isn't there, escalate."
What's in this folder
README.md— this filecover-image.png— cover artmetadata.md— generation metadatarequirements.md— functional/non-functional spec, including the decoding rules tableindex.html,style.css,script.js— the appsample-data.json— 17 syntheticIdentityRequestrecords covering all four decoded buckets, including matched pairs of "verification timeout, access present" and "verification timeout, access missing"
How to run / read it
Open index.html in any modern browser. If the browser blocks local fetch() calls from file://, run python3 -m http.server in this folder and open http://localhost:8000 instead.
Estimated impact
No hard number here. This is a design assumption, not a measured result. The claim it rests on: if a meaningful share of "Terminated" verification requests in a given IIQ instance are false failures (access already granted, read-back just timed out), then every one of those that gets auto-classified instead of hand-investigated by an engineer is a ticket the help desk can close on the spot instead of routing upstream. The actual rate would need to be measured against a real deployment's IdentityRequest history before anyone should plan headcount around it.
Why this fits an IIQ shop with 500+ connectors
Verification read-back depends on the target connector's aggregation timing, and at 500+ connectors that timing is wildly inconsistent. A fast JDBC app confirms in seconds; a batch mainframe connector might not aggregate until the next nightly run. The wider that spread gets, the more "Terminated" requests are really just slow connectors outrunning maxVerificationDays, not broken ones. A fixed status page can't tell the difference at any scale. A decoder that cross-references the actual entitlement state can, connector by connector.
Sources
- Official documentation:
https://documentation.sailpoint.com/identityiq/help/lifecycle_manager/lifecyc_manager_compo.html— Track My Requests component: the Completion Status values (Pending, Approved, Rejected, Completed, Cancelled, Completed Pending Verification) and Execution Status values (Executing, Verifying, Terminated, Completed) this app's decoding rules are built from.
- Community / current research:
https://developer.sailpoint.com/discuss/t/access-request-error/207057— community thread describing an access request where the entitlement was granted but the request stayed "Incomplete" after a verification timeout, including the "This request timed out waiting for verification of one or more items" error text and themaxVerificationDayssetting on the Identity Request Maintenance task.
Requirements
Requirements — IIQ Request Status Decoder
Purpose
A read-only, single-page app that translates IdentityIQ IdentityRequest completion/execution
status pairs into a plain-English answer for the two questions a help desk agent or end user
actually asks: "did I get the access?" and "do I need to escalate this?" It also flags the one
state where those two statuses lie to each other — a request stuck in Terminated execution
after maxVerificationDays even though the entitlement already landed on the target system.
Functional requirements
- Load data. On page load,
fetch("sample-data.json")and parse into an array ofIdentityRequest-shaped records. No build step, no bundler, no CDN dependency. - Request list.
- Render every request as a row: Request ID, requestee, description, application, request
date, and a decoded status pill (see decoding rules below) instead of the raw
completionStatusstring. - Filter chips:
All,In Progress,Needs Escalation,False Failure (no action),Done. Exactly one filter active at a time. - Free-text search box matches Request ID, requester, requestee, description, and application (case-insensitive substring match).
- Clicking a row selects it and loads the detail panel. The first request in the list is selected by default on load.
- Render every request as a row: Request ID, requestee, description, application, request
date, and a decoded status pill (see decoding rules below) instead of the raw
- Decoding rules (implemented once in
script.js, not duplicated in the DOM layer):completionStatus: "Completed"→ Done. "Access is active on <application>."completionStatus: "Pending"→ In Progress. "Waiting on <currentStep>." No escalation.completionStatus: "Rejected"→ Done (denied). "<currentStep> denied the request."completionStatus: "Cancelled"→ Done (cancelled). "Requester cancelled before provisioning."completionStatus: "Completed Pending Verification"withexecutionStatus: "Verifying"anddaysInVerification < maxVerificationDays→ In Progress. "Provisioned; IIQ is confirming the read-back on <application>. Normal — should clear within <maxVerificationDays - daysInVerification> day(s)."completionStatus: "Completed Pending Verification"withexecutionStatus: "Terminated"(i.e. the verification window in the Identity Request Maintenance task'smaxVerificationDayselapsed) andentitlementConfirmedOnTarget: true→ False Failure, no action. "Access IS present on <application> — verification timed out on the read-back, not the grant. Do not re-provision; close the ticket with this explanation."- Same
Terminatedcase butentitlementConfirmedOnTarget: false→ Needs Escalation. "Access was NOT found on <application> after the verification window closed. Escalate to IAM engineering with this Request ID — provisioning likely failed silently."
- Detail panel.
- Header: Request ID, type, requester → requestee, application, request date.
- Decoded status banner (large, colored by category: in-progress = blue, done = green, false-failure = amber, needs-escalation = red) with the full explanation sentence from the decoding rules.
- Raw fields table:
completionStatus,executionStatus,currentStep,entitlementConfirmedOnTarget,lastAggregationCheck,daysInVerification/maxVerificationDays— so an agent who wants the underlying IIQ values can still see them next to the plain-English read. - Suggested action line, one sentence, tied to the category (e.g. "No action — reply to the requester with the explanation above" vs. "Escalate to IAM engineering, priority high").
- Summary bar above the list: total requests, count in each of the four filter categories. Recomputed from the currently loaded dataset, not hard-coded.
- No auth, no network calls beyond the local
fetch. The app must open directly viafile://(falling back topython3 -m http.serverif the browser blocks localfetch) with no login, no API key, and no external endpoint.
Non-functional requirements
- Vanilla HTML/CSS/JS only. No frameworks, no CDN scripts.
- Dark theme, consistent with the rest of the IAM-Ideas App folders.
- All rendering paths must escape user-visible strings pulled from JSON (see
escapeHtmlinscript.js) since descriptions and requester/requestee names could, in a real deployment, contain characters someone typed into a free-text field. - The dataset must include at least one record in each decoded category — Done, In Progress
(both plain-pending and mid-verification), False Failure, and Needs Escalation — so every
branch in the decoding rules is exercised by
sample-data.json.
What this app is not
- It does not connect to a live IdentityIQ instance. Production wiring would poll the
IdentityRequestREST resource (or a scheduled export) plus aLink/aggregation read-back to populateentitlementConfirmedOnTarget— neither is in scope for this prototype. - It cannot cancel a request, resend a reminder, or reassign a work item — those already exist on IIQ's native "Track My Access Requests" quicklink. This app is a triage lens on top of that data, not a replacement for it.
- The
entitlementConfirmedOnTargetfield simulates what an aggregation/read-back cross-check would report. It is not sourced from a real target-system query in this prototype — seeUnverified assumptionsinmetadata.md.
More from IAM Ideas
