IIQ Joiner Day-1 Readiness Tracker

A single-page operator dashboard that surfaces provisioning completeness for every new hire starting in the next 7 days, so the IAM team knows who is not ready before the employee walks in the door.

Date: 2026-06-15 Type: App Theme: UX + Detect Platform: SailPoint IdentityIQ Status: Idea

What it is

A static browser app that aggregates IIQ Joiner lifecycle event data, ProvisioningTransaction results, and open Work Items into a single readiness view. It shows each incoming hire's expected application set (derived from their assigned IIQ Bundles/Roles), which accounts are provisioned, which are still pending, and which have hard failures — ranked by urgency (hours until start date). Operators can click any row to see a per-application breakdown with failure reasons and work item owners.

Who it serves

The IAM operations engineer or IIQ administrator who owns day-1 provisioning quality. They currently have to correlate three separate IIQ surfaces — the Lifecycle Events Status Report, the ProvisioningTransaction grid, and the Work Items queue — to answer "which new hires are not ready?" This app collapses that to one triage screen they can act from in under five minutes.

The IIQ pain it addresses

IIQ's Joiner lifecycle event fires when an authoritative source (typically Workday or an HR JDBC connector) publishes a new hire record during a Refresh Identities task run. The event triggers a BPM workflow that generates a ProvisioningPlan and fans out provisioning requests across every Application that the new hire's assigned Bundles require. In a shop with 500+ connectors, that fan-out can touch 4–10 applications per joiner. Several failure modes compound invisibly:

• Connector-level provisioning failures (unique constraint violations, null attribute values from a FieldValueRule, connector throttle limits) block one application without surfacing the blockage in the Joiner event status view.
• Open Work Items from approvals or manual provisioning steps sit unworked in the generic Work Items queue — there is no native view that shows "these work items are for joiners starting today."
• Joiner event not fired — if the HR aggregation ran late or the Refresh Identities task hasn't executed, lifecycleEventFiredAt is null and the hire is entirely invisible to the provisioning pipeline.

The result: new employees arrive on day 1 without access to core business systems, opening a helpdesk ticket, losing productive time, and eroding trust in the IAM program.

How it works

On load, script.js fetches sample-data.json (in production: two IIQ REST calls — GET /identityiq/rest/identities?filters=lifecycle==Joiner and GET /identityiq/rest/provisioningTransactions?filters=created>={T-7d} — merged client-side) and renders:

1. KPI bar — five clickable tiles: Total Joiners (7-day window), Fully Ready, Partial, At Risk (start < 8 h, incomplete), Failed. Clicking a tile filters the table to that cohort.
2. Filter bar — free-text search, department dropdown, status dropdown, reset. Result count updates live.
3. Sortable table — default sort: Hours Until Start ascending (most urgent first). Rows with start < 4 h and incomplete provisioning show a red URGENT badge; 4–8 h shows amber SOON. The Readiness column shows a colour-coded progress bar (green → amber → red) and a percentage.
4. Detail drawer — clicking a row slides in a panel showing every expected application with its provisioning status badge, account ID, completion timestamp, failure reason, and work item owner. A console shortcut tells the operator exactly where to go in IIQ to intervene.

No network calls are made in the prototype — the sample data covers 18 synthetic joiners across 7 departments and 14 distinct applications spanning Active Directory, SAP, Workday, Salesforce, GitHub Enterprise, AWS IAM, Splunk, CrowdStrike, and others.

What's in this folder

• index.html — single-page entry point, opens from file://, no build step
• style.css — deep-navy/electric-blue design system with status colour coding
• script.js — vanilla JS: data loading, filter/sort, table rendering, drawer logic, IIQ REST documentation inline
• sample-data.json — 18 synthetic IIQ-shaped joiner records with realistic per-app provisioning state and failure reasons
• requirements.md — functional requirements, IIQ data source mapping, and out-of-scope definition
• cover-image.png — concept art cover (16:10, no text, no logos)
• metadata.md — generation metadata

How to run / read it

Open index.html in any modern browser (Chrome, Firefox, Edge, Safari). No server, no auth, no build step. The page loads sample-data.json from the same directory. Click any row to open the per-identity provisioning drawer. Click KPI cards to filter. Sort any column by clicking its header.

Estimated impact

In an organisation with 100+ joiners per month, IAM engineers currently spend 2–3 hours on the Monday/Tuesday morning before a start wave chasing down failed provisioning plans across three IIQ screens and a helpdesk ticket queue. This app consolidates that into a 10-minute morning triage check, saving approximately 8–12 engineer-hours per month and eliminating the class of "day-1 no access" helpdesk tickets that stem from provisioning failures the team didn't know about.

Why this fits an IIQ shop with 500+ connectors

At scale, a Joiner event is not one provisioning action — it is a fan-out across dozens of connectors, each with its own retry semantics, rate limits, approval gates, and FieldValueRule dependencies. A single null return from a manager attribute rule blocks Active Directory, which cascades to block every downstream application that depends on an AD account. An operator monitoring the native Lifecycle Events Status Report sees "Completed with warnings" and has no reason to drill in. This app makes the long tail of partial failures visible in a single cohort view at the moment they matter most — before the employee's first meeting.

Sources

• Lifecycle Events Status Report — SailPoint IdentityIQ docs — IIQ's native report covering Joiner/Mover/Leaver access request status; confirms the field set available and what is NOT surfaced (per-app provisioning failures are not a first-class column)
• Lifecycle Event-Driven Provisioning — SailPoint IdentityIQ docs — Joiner event trigger, BPM workflow invocation, and ProvisioningPlan generation semantics
• Recording Provisioning Requests — SailPoint IdentityIQ docs — ProvisioningTransaction object and how IIQ records the result of each provisioning action
• Joiner Failure While Provisioning — SailPoint Developer Community — Community thread documenting the FieldValueRule / manager attribute type-mismatch failure mode that causes selective Joiner failures across a subset of users
• Access Request State/Status — SailPoint Compass — Compass article on IdentityRequest and provisioning status definitions used in the Status column design
• Using Lifecycle Manager — SailPoint IdentityIQ docs — Lifecycle Manager overview including Joiner, Mover, Leaver event configuration