Iiq Workflow Case Xray
A browser-runnable case timeline for stalled SailPoint IdentityIQ workflows, so you can see which step a case is actually stuck on before you open the Debug pages or the console.
IIQ Workflow Case X-Ray
A browser-runnable case timeline for stalled SailPoint IdentityIQ workflows, so you can see which step a case is actually stuck on before you open the Debug pages or the console.
Date: 2026-08-03 Type: App Theme: Observability + Respond Platform: SailPoint IdentityIQ Status: Idea
What it is
A single-page HTML/JS/CSS app that loads a set of IIQ WorkflowCase records and renders each one as a step-by-step timeline: which steps completed, how long each took, which step is current, and how long the case has been sitting there. Cases that look stuck rather than merely slow are flagged, with a plain-language note on what to check first.
Who it serves
The IAM engineer who gets pulled in when a joiner's account still isn't provisioned two days after the manager approved it. Right now that means opening the Debug pages, filtering the object browser for WorkflowCase, and reading raw XML to find the currentStep. This app is what that triage should look like: a list of in-flight cases, sorted so the stuck ones are obvious, with the timeline already laid out.
The IIQ pain it addresses
IIQ's workflow engine tracks an in-progress case as a TaskResult, and the documented way to inspect it is the Setup > Tasks > Task Results page. That page shows what's complete and what's pending, but it stops there. It won't tell you whether "pending" means a manager hasn't opened their work item yet, or the case is actually broken. For deeper detail, IIQ's own docs point to the Debug pages (filter the object browser on WorkflowCase) or the console commands list workflowcase and get workflowcase "<name>", both of which dump raw case XML and expect you to find currentStep by hand.
That gap is a real, recent complaint, not a hypothetical one. A SailPoint developer community thread describes a workflow case that stayed pending even after its approval work item finished and after running Perform Maintenance, with the underlying access already provisioned to the target system. The thread's own troubleshooting checklist: turn on the trace workflow variable, check Catalina logs, look for a custom rule throwing an exception, check for orphaned work items. That's the right list, and it's entirely manual. It also assumes the engineer already knows the case is stuck rather than just running late.
How it works
- Load. The app fetches
sample-data.json, an array of case records shaped like a parsedWorkflowCaseexport: case ID, workflow name, identity, target applications, current step, per-step status and timestamps, process variables, and any linked work items. - Case list. Every case appears as a row with its status badge (Pending / Completed / Failed) and a flag dot for cases judged stuck. Filter chips narrow to Flagged, Pending, Completed, or Failed; a search box matches case name, identity, workflow, or target app.
- Timeline. Selecting a case renders its steps as a vertical timeline: green dots for completed steps with their elapsed time, an amber dot for the current step with hours-in-step, grey for steps not yet reached, red for a failed step. A step past the staleness threshold gets a warning marker.
- Flag banner. Flagged cases show a one-line note on the likely cause, drawn from the same checklist the community thread used: a finished approval that didn't unblock the case, a step waiting on an external callback that never arrived, or a rule exception that needs trace logging to see.
- Illustrative XML. A "View illustrative XML" button renders the selected case as a
<sailpoint><WorkflowCase>document in the shape the docs describe for aget workflowcaseexport, with an explicit note that it's generated for this demo and needs checking against a real 8.4 deployment before anyone treats the field names as gospel.
What's in this folder
README.md— this filecover-image.png— card cover illustrationmetadata.md— workflow metadata sidecarrequirements.md— functional requirements, including what the app deliberately does not doindex.html— single-page entry point, opens in any modern browser viafile://style.css— dark-theme stylesscript.js— data loading, filtering, timeline rendering, and the illustrative XML builder (vanilla JS, no dependencies)sample-data.json— 15 synthetic IIQ-shapedWorkflowCaserecords spanning Joiner, Mover, Leaver, access request, SOD remediation, and break-glass workflows across AD, Workday, SAP, ServiceNow, Salesforce, GitHub, Entra ID, RACF, and AWS IAM/CyberArk
How to run / read it
Open index.html in any modern browser. No server, no auth, no npm.
# If fetch() is blocked by browser security on file:// URLs, start a minimal server:
python3 -m http.server 8080
# then visit http://localhost:8080
The default view loads with the first case selected: WFCase-100482, a joiner case flagged because its approval work item finished but provisioning to AD never advanced. Seven of the fifteen sample cases are flagged; two of those are genuinely waiting on a human rather than stuck, which the flag logic correctly leaves unflagged.
Estimated impact
A mid-sized IIQ team fielding "why hasn't my access come through" tickets typically spends 15 to 30 minutes per stuck case just getting to the point of knowing which step it's on: opening the Debug pages, filtering the object browser, reading raw case XML. A dashboard that surfaces flagged cases up front and lays the timeline out visually cuts that to a couple of minutes of scanning. That matters most in the exact scenario this idea is built around: a joiner or leaver case stuck on day one, where the delay is visible to the business.
Why this fits an IIQ shop with 500+ connectors
At 500+ connectors, workflow steps hit wildly different failure modes depending on the target system. An AD provisioning step fails fast and loud. A mainframe RACF step is slow by design because it waits for an overnight batch job. A ServiceNow callback step can wait indefinitely for an integration that silently broke. A single "how long has this been pending" number can't tell those apart. This app's sample data deliberately includes a RACF case that looks stalled by a naive threshold but isn't, next to an AD case that looks similarly stalled and genuinely is. The flagging logic has to reason about what's actually blocking the step, not just elapsed time, which is the same judgment call a large IIQ shop's on-call engineer makes dozens of times a week.
Sources
- Official documentation:
https://documentation.sailpoint.com/identityiq_84/help/businessprocesses/wf_monitoringworkflows.html— confirms the TaskResult is the object that holds in-progress workflow state and that Setup > Tasks > Task Results is the documented way to see what's complete versus pendinghttps://documentation.sailpoint.com/identityiq_84/help/businessprocesses/wf_viewworkflowcase.html— confirms the Debug pages' WorkflowCase XML view and the exact IIQ console commands (list workflowcase,get workflowcase "<name>") used to inspect a case's current step
- Community / current research:
https://developer.sailpoint.com/discuss/t/workflowcase-pending-even-running-perform-maintenance/211968— the real, recent practitioner thread this idea is built around: a workflow case stuck pending after its approval finished, with the community's own manual troubleshooting checklist (trace logging, Catalina logs, custom rule exceptions, orphaned work items, Perform Maintenance's "process background threads" setting)
Requirements
Requirements — IIQ Workflow Case X-Ray
Purpose
A read-only, single-page app that renders IdentityIQ WorkflowCase data as a step timeline
so an engineer can see, at a glance, where a case is stuck and what to check next — without
opening the Debug pages or the IIQ console for every case.
Functional requirements
- Load data. On page load,
fetch("sample-data.json")and parse into an array of case records. No build step, no bundler, no CDN dependency. - Case list.
- Render every case as a row: case name, workflow name, current step name, status badge
(
Pending/Completed/Failed), and a flag dot ifflagged: true. - Filter chips:
All,Flagged,Pending,Completed,Failed. Exactly one filter active at a time. - Free-text search box matches case name, identity name, workflow name, case ID, and target application names (case-insensitive substring match).
- Clicking a row selects it and loads the detail panel. The first case in the list is selected by default on load.
- Render every case as a row: case name, workflow name, current step name, status badge
(
- Detail panel.
- Header: case name, and a subline with case ID, workflow name, identity name, and target applications.
- Flag banner: visible only when
flagged: true; shows thesuspectedCausetext verbatim. - Step timeline: one row per entry in
steps[], in array order, each showing step name, status (Completed/Current/Pending/Failed/Not Reached), and either the elapsed time betweenenteredAt/exitedAt(completed steps) or hours-in-step (the current step). A step whosestatusisCurrentand whose case-levelhoursInCurrentStepis at or aboveSTALE_THRESHOLD_HOURS(8, configurable inscript.js) shows a warning marker next to its elapsed time. - Process variables table: every key in
variables{}rendered as a row. Empty state reads "None recorded". - Work items table: every entry in
workItems[]rendered as type + owner + state (+ completion timestamp if present). Empty state reads "No work items associated with this case".
- Illustrative XML view. A "View illustrative XML" button opens a modal that renders the
selected case as a
<sailpoint><WorkflowCase>...</WorkflowCase></sailpoint>XML document, built client-side from the same record. The modal text explicitly states the XML is structurally illustrative, generated for this demo, and must be checked against a realget workflowcaseexport before anyone treats its field names as authoritative. - 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 case names and variable values could, in a real deployment, contain characters an operator typed into a request justification field. - The dataset must include at least one case in each of these states so the UI's branches are all exercised: a flagged/stalled Pending case, a non-flagged Pending case genuinely waiting on a human approver, a clean Completed case, and a Failed case.
What this app is not
- It does not connect to a live IdentityIQ instance. Production wiring would require either a
scheduled export of in-flight
WorkflowCaseobjects (via a custom Task calling theget workflowcaseequivalent through IIQ's Java API) or a REST proxy — neither is in scope for this prototype. - It is not a workflow editor. It only visualizes case state; it cannot retry a step, reassign a work item, or edit workflow XML.
- The stale-step heuristic (
hoursInCurrentStep >= 8) is a starting default, not a documented IIQ threshold — different steps (human approval vs. connector provisioning vs. a mainframe batch job) have very different normal durations, and a real deployment would need per-step or per-workflow thresholds instead of one global number.
More from IAM Ideas
