IIQ Provisioning Pending Sentinel

Polls IdentityIQ's own Provisioning Transaction table for requests stuck in Pending or Failure past a set age, and pushes one Slack alert per stuck request instead of waiting for someone to check the Administrator Console.

Date: 2026-08-24 Type: Integration Theme: Detect + Automation Platform: SailPoint IdentityIQ Status: Idea

What it is

A scheduled IIQ Task that reads the same Pending and Failure data the Administrator Console's Provisioning page already shows, filters it down to requests that have been stuck longer than a configurable threshold, and posts a Slack message for each one with the identity, application, operation, and — where the request is blocked on a manual ticket rather than a live connector call — the linked ticket ID and its current status. It doesn't retry anything and doesn't touch provisioning. It just makes sure a stuck request shows up somewhere a human is actually looking.

Who it serves

The IAM engineer on the rotation that owns provisioning health, and by extension the new hire or the terminated employee whose account is the thing sitting stuck.

The IIQ pain it addresses

IdentityIQ's Administrator Console already has a Provisioning page with All, Failure, Success, and Pending tabs, plus a Retry button for anything recorded as retryable. That page works fine — the problem is nobody's watching it. A couple of early-2026 threads on the SailPoint Developer Community describe exactly this: an account request parked at "Execution Status: Verifying" for days even after running Perform Identity Maintenance, and a separate report of provisioning hanging in Pending while "waiting on a manual process or a disconnected server." Both are visible on the Provisioning page the moment they happen. Neither generates a notification.

The manual-ticket path makes it worse. At 500+ connectors, a real slice of provisioning goes through an ITSM ticket rather than an API call — mainframe apps, anything without a REST connector, anything a vendor still wants a human to touch. IdentityIQ's own Jira Service Management connector maps external ticket statuses back to IIQ's provisioning status through a configured statusMap, and its troubleshooting page documents the exact failure this creates: a ticket status that isn't in the map leaves the provisioning transaction with nowhere to go. The example in that documentation is a ticket resolved in Jira with no corresponding "Resolved" entry in the status map — provisioning just sits there. This sentinel is built to catch that specific case, not just a generic timeout.

How it works

Every 15 minutes, an IIQ Task queries ProvisioningTransaction for anything in Pending or Failure status older than the configured threshold (240 minutes by default). For each match it pulls the identity, application, operation type, and — when the transaction carries a linked ticket ID — the ticket's current status, then checks a small dedupe record so the same stuck transaction doesn't re-alert every 15 minutes; it only re-fires after an escalation window if the problem is still there. Each stuck transaction becomes one Slack message via an Incoming Webhook, formatted with Block Kit so the identity, application, and status are readable without opening IIQ.

If Slack itself is unreachable or the webhook is misconfigured, the task doesn't fail silently on the very problem it exists to catch — it logs an error to its own TaskResult, the same place a stuck aggregation would show up, so a broken alert pipe is itself visible on the Task Results page.

What's in this folder

• integration-spec.md — the full contract: systems, auth, endpoints, payload shapes, error model, sequencing, and operational assumptions, including the one field (a ticket-ID attribute on ProvisioningTransaction) this idea couldn't confirm from a fetched page.
• sequence.md — the happy path (one stuck transaction, one Slack alert) plus a failure case where the webhook itself is broken.
• sample-request.json — the Slack Block Kit payload the sentinel posts for one stuck transaction.
• sample-response.json — Slack's success response body.

How to run / read it

Read integration-spec.md first for the full contract, then sequence.md for how a 15-minute cycle actually plays out, then the sample request/response pair for the one HTTP call this integration makes — to Slack. The IIQ side of the contract is an internal task query against ProvisioningTransaction, not a network call, and its filter logic is documented in integration-spec.md §6.1.

Estimated impact

No hard number here without a real deployment's stuck-transaction count to measure against. What's concrete is the gap being closed: today, finding a stuck provisioning transaction requires someone to open the Administrator Console and look at the Pending tab. This turns that into a push, at whatever cadence the 15-minute schedule and 4-hour threshold are tuned to. For a Leaver-disable transaction specifically, closing that gap by even a few hours matters more than the average — it's the difference between an account staying live for one shift or three.

Why this fits an IIQ shop with 500+ connectors

Provisioning at that scale runs through a long tail of connector types with very different failure modes — some retry cleanly on a transient API error, some sit blocked on a person in another system entirely. A single generic "provisioning is slow" alert doesn't help an engineer triage which of those they're looking at. Reading the ticket status straight off the transaction, when one exists, is what turns a Slack message into something actionable instead of another thing to go look up.

Sources

1. Official documentation:
   • https://documentation.sailpoint.com/identityiq_84/help/systemadmin/adminconprovtran.html — confirms the Provisioning Transaction table's All/Failure/Success/Pending tabs, that "retryable errors are recorded as Pending transactions," the Retry action, and the Override-to-manual-work-item path for transactions that can't retry
   • https://documentation.sailpoint.com/connectors/identityiq/itservice/help/it_service_management_infrastructure_modules/troubleshooting_for_jira_service_management.html — documents the Jira Service Management connector's provisioning statusMap, and gives the exact error this idea targets: a ticket status not defined in the status map leaves provisioning unresolved
   • https://docs.slack.dev/messaging/sending-messages-using-incoming-webhooks — Incoming Webhook request/response shape, including the invalid_payload, channel_not_found, no_service, and no_text error identifiers used in this spec's error model
2. Community / current research:
   • https://developer.sailpoint.com/discuss/t/how-to-fix-provisioning-pending-issues-in-identityiq-8-3/184892 — a January 2026 report of an account request stuck showing "Execution Status: Verifying" even after a Perform Identity Maintenance run
   • https://developer.sailpoint.com/discuss/t/provisioning-task-hangs-in-pending-state/195878 — a February 2026 report of provisioning hanging in Pending while waiting on a manual process or a disconnected server