IIQ Aggregation Freshness Radar

A single-pane ops console that surfaces stale, partially-failing, and drifting account aggregations across a 500+ connector SailPoint IdentityIQ estate — in seconds.

The pain

IIQ's native Task Results UI is fine when you have a dozen connectors. With 500+ apps and tens of thousands of identities it becomes a needle-in-a-haystack search. Three failure modes reliably go unnoticed for days — sometimes weeks — and each one corrodes trust in IIQ as the system of record:

1. Stale aggregations. A connector silently stops aggregating — the scheduled task is disabled, the credential has rotated, the source endpoint has been decommissioned. The Task Results screen still shows old "Success" rows; nothing screams. By the time a certifier flags missing accounts, weeks have passed.
2. Partial failures. A run aggregates 49,800 of 50,000 accounts and exits "Success" with warnings buried in the task XML. Those 200 missed accounts become orphan-or-ghost identities in the next certification.
3. Drift. Active Directory says 53,210 enabled users; IIQ's last aggregation captured 53,180. A 0.06% gap is noise — until the same connector drifts 2% next week. Nobody is watching the trend.

This app is the dashboard the operator wishes existed inside IIQ.

What it is

A runnable, single-page web console — open index.html in any modern browser, no build step, no auth, no API keys. It loads sample-data.json (24 synthetic connectors mirroring a realistic IIQ estate — AD, Azure AD/Entra, Okta, Workday, ServiceNow, Salesforce, SAP, GitHub, AWS IAM, Linux/Unix, mainframe, plus a long tail of custom JDBC apps) and renders:

• KPI strip — total connectors, stale (> 48h), partial-failure runs in last 24h, drift > 1%.
• Health filters — All / Green / Amber / Red, plus a free-text search and a category filter (Directory, HRIS, ITSM, SaaS, Cloud, On-prem, Custom).
• Connector list — one row per connector with a colored health badge, last-aggregation timestamp, drift %, and partial-failure ratio.
• Detail panel — click a connector to see its last 10 runs, a duration sparkline (early-warning for slow source systems), a drift gauge, and a partial-failure breakdown by error class.
• Radar view — an SVG concept layout that arranges connectors radially by category, sized by identity count, colored by health. Useful for an at-a-glance readout in a NOC or ops review.

Health is computed from a transparent composite:

score = 0.40 * freshness_score
      + 0.30 * drift_score
      + 0.30 * partial_failure_score

Each component is normalized 0–1 so the formula can be tuned in script.js without rewriting the UI.

Why it matters

How to run

# Just open the file. No npm, no build, no server.
start index.html         # Windows
open  index.html         # macOS
xdg-open index.html      # Linux

If your browser blocks fetch('sample-data.json') from file://, serve the folder with any static server:

python -m http.server 8765
# then visit http://localhost:8765

Path to production

This is a prototype with synthetic data. To make it real:

1. Backend. A small read-only service that calls IIQ's /identityiq/rest/tasks (or queries the spt_task_result and spt_identity_request tables directly) on a 5-minute schedule and caches normalized health metrics in Postgres or Redis.
2. Drift source. Per connector, register a "source-of-truth count" probe — Get-ADUser -Filter 'Enabled -eq $true' | Measure-Object for AD, users.list for Okta, etc. Compare to the last aggregation's link count.
3. Auth. SAML/SSO behind your standard IAM admin role (Identity IQ Administrator or a custom capability).
4. Alerting. Wire amber/red transitions to ServiceNow / PagerDuty / Slack via the existing IIQ workflow that already issues notifications — reuse, don't reinvent.
5. History. Persist daily snapshots so the radar can replay "what did the estate look like last Tuesday?" — invaluable in incident reviews.

Files

Caveats

• Synthetic data only. Numbers are illustrative; the drift gauge does not reflect any real environment.
• No network calls. The prototype is intentionally air-gapped to prove the value before any backend lift.
• Vanilla JS, no framework. One file per concern, no build chain — matches the IAM-Ideas runnable-from-file:// rule.