IIQ Workflow Health & Aging Report

A weekly snapshot of BPM WorkflowCase age and failure distribution, giving IAM operators a ranked remediation queue before stuck cases cascade into provisioning outages or SLA breaches.

Date: 2026-06-22 Type: Report Theme: Observability + Respond Platform: SailPoint IdentityIQ Status: Idea

What it is

A scheduled weekly report that reads active WorkflowCase objects from IIQ, buckets them by age, identifies stuck cases (age > 24 hours with no step progression), and ranks them by business impact — by identity, application, and workflow type. The report is designed to be emailed to the IAM operations team each Monday morning and to serve as an audit artifact for SLA commitments on access provisioning.

Who it serves

IAM engineers and IIQ administrators who triage provisioning failures and workflow incidents. Secondary audience: GRC analysts who need SLA evidence for access provisioning controls (SOX, ISO 27001 PR.IP-7). The report surfaces what IIQ's native Process Monitor hides: a ranked, age-weighted view of the workflow backlog, not a flat list of task results or a one-at-a-time Debug Object Browser.

The IIQ pain it addresses

IIQ's Business Process Monitor (Setup > Tasks > Task Results) lists WorkflowCase objects one at a time without age ranking, SLA projection, or step-level aggregation. When a connector outage drops 40 LCM Provisioning cases into a stuck state, operators discover it from a user complaint or a manual scan of the Debug Object Browser — both reactive and unscalable at 500+ connectors. The WorkflowCase object carries step-level state (currentStep, complete, taskResultId), but IIQ has no native report that aggregates this into an operator-facing aging queue. A case stuck at Provision Account for 7+ days is not the same risk as one stuck at Approve Request for 2 hours — but the native UI treats them identically. The SailPoint community has repeatedly documented this gap: the official remediation guidance is "filter the Debug Object Browser for cases created more than 1 day ago and delete them" — which is reactive, manual, and produces no audit trail.

How it works

1. Data extraction — A scheduled TaskDefinition backed by a LiveReportExecutor (or a weekly script calling GET /identityiq/rest/workflows/cases) reads spt_workflow_case joined with spt_work_item, spt_identity_request, and spt_task_result. It computes case age from the created timestamp and classifies each case as Active, Pending-Approval, Stuck (> 24 h), or Stale (> 7 d).
2. Step hotspot aggregation — The report groups stuck cases by currentStep name to identify systemic step-level failures. A connector that goes dark on Monday afternoon will show up Tuesday morning as a spike in "Provision Account" step cases.
3. Identity and application ranking — Cases are cross-referenced to spt_identity and spt_application to surface the identities with the most blocked provisioning work and the applications most frequently represented in stuck cases.
4. 4-week trend — The report appends to a rolling 4-week snapshot so operators can distinguish a one-day spike from structural backlog growth.
5. Distribution — The rendered report is emailed as a Markdown → HTML document to the IAM operations DL each Monday at 07:00. It also writes a row to spt_audit_event with action = workflow_health_report_generated for audit trail completeness.

What's in this folder

• README.md — This document.
• metadata.md — Workflow run metadata, model, and IIQ surface references.
• report.md — Fully rendered weekly report for the week of 2026-06-15 → 2026-06-21 with realistic but synthetic numbers.
• report-template.md — Parameterised version of the same report with {{placeholders}} for every data-supplied value.
• sample-data.json — Synthetic dataset matching the template placeholder shape; also serves as the schema reference for the data extraction step.
• cover-image.png — Cover art (16:10, no text).

How to run / read it

Open report.md for the rendered version. See report-template.md for the placeholders and sample-data.json for the shape of the source data. The sample data is ready to bind against the template to reproduce the rendered report.

In production, the data extraction step would be a scheduled IIQ TaskDefinition of type LiveReport; alternatively, the IIQ console command List workflowcase exports current cases to a CSV that feeds the same template.

Estimated impact

At a 500-connector IIQ deployment with 50k+ identities, a typical provisioning week generates 300–500 active WorkflowCase objects. Stuck case rates of 15–20% are common following a connector blip or BPM rule change. Without a weekly health report, the mean-time-to-discover (MTTD) for a stuck provisioning batch is 3–5 days (the first user complaint). This report reduces MTTD to under 18 hours (next Monday's run) and converts the remediation queue from "whoever files a ticket first" to a ranked list ordered by age and identity impact. Estimated savings: 4–6 hours/week of ad-hoc triage currently done by searching the Debug Object Browser and cross-referencing inbox complaints.

Why this fits an IIQ shop with 500+ connectors

At 500+ connectors, any provisioning event fans out across a long tail of applications whose connectors have varying reliability. A stuck WorkflowCase on a low-traffic connector (mainframe, legacy JDBC, custom on-prem app) can go unnoticed for weeks because no user complains until they actually try to use the account. The step-level hotspot section of this report is specifically designed to catch that pattern: a single connector going dark shows up as a cluster of cases stuck at the same step name, visible only when you aggregate across the full case population rather than viewing cases one at a time. That aggregation becomes more valuable — not less — as the connector estate grows.

Sources

• SailPoint IIQ — Monitoring Workflows — WorkflowCase monitoring approach, console commands (List workflowcase, get workflowcase), and Debug page Object Browser; primary reference for the data extraction approach
• SailPoint IIQ — Workflow Basics — WorkflowCase / WorkflowContext / TaskResult object semantics; workflow type classifications (LCM Provisioning, Identity Lifecycle, Role Assignment, etc.) used in the report's type breakdown section
• SailPoint Developer Community — WorkflowCase Pending after Perform Maintenance (2026-06-02) — Documents IIQ 8.4 case where approval WorkItem completes but parent WorkflowCase never progresses to provisioning; motivates the "stuck after approval" step-hotspot category in §3
• SailPoint Compass — Troubleshooting stuck workflows — Canonical Compass article establishing that the current best practice is a manual Debug Object Browser scan for cases older than 1 day; the absence of a proactive report in this guidance directly motivates this idea
• SailPoint Compass — Rule the world: Delete WorkItems and WorkflowCases — Documents the parent-child relationship between WorkflowCase and WorkItem; informs the report's distinction between cases stuck at an approval step (WorkItem present) vs. stuck at a provisioning step (no pending WorkItem)
• IDMWORKS — Business Processes IIQ Troubleshooting — Third-party confirmation that native IIQ workflow troubleshooting guidance is limited to the trace flag, with no aggregate health surface — the gap this report addresses