SailPoint IdentityIQ: Taming the Aggregation-to-Provisioning Pipeline

I have run IdentityIQ in environments where it sang and environments where it was a nightly source of dread. The difference was rarely the product and almost always the operating discipline around its core pipeline: aggregate, correlate, refresh, provision. Get the mental model right and IIQ is remarkably capable. Get it wrong and you will spend your evenings chasing identity cubes that won't update.

Aggregation is reading, provisioning is writing — keep them straight

The most common conceptual error is conflating the two directions. Aggregation pulls account and entitlement data from a target system into IIQ. Provisioning pushes changes to a target system. They use different parts of the connector, fail for different reasons, and need different troubleshooting. When access "isn't showing up," the first question is always: is this an aggregation problem (IIQ can't read it) or a provisioning problem (IIQ couldn't write it)?

Correlation: the silent killer of data quality

Correlation is how IIQ decides that an account on a target system belongs to a given identity. When correlation logic is weak, you get uncorrelated accounts — orphans that IIQ sees but can't attribute to a person — and these quietly undermine everything downstream: certifications miss them, leaver processes skip them, and your "complete" access picture has holes. Invest disproportionate effort in correlation rules and the authoritative attributes they rely on. It is unglamorous and it is foundational.

Identity refresh: where the cube comes together

The identity refresh task is what recomputes each identity's state — roles, entitlements, policy violations, risk scores — from aggregated data. If aggregation is stale or refresh hasn't run, the cube lies, and decisions made against a lying cube are wrong. Sequence matters: aggregate first, then refresh. Scheduling these out of order, or letting aggregation lag, is behind a surprising share of "why is IIQ showing old access?" incidents.

Provisioning: plan for partial failure

Provisioning to a dozen heterogeneous targets will partially fail. A connector times out, a target rejects a change, a downstream approval stalls. The question is whether your design treats that as a managed state or a silent loss. Use provisioning plans with proper retry and error surfacing, and make sure failed provisioning generates a visible work item, not a log line nobody reads. Idempotency matters here too: a retry must not create duplicate access.

Customise with restraint

IIQ's flexibility is a trap. Every custom rule, workflow, and connector tweak is something you must maintain across upgrades, and the platform's upgrade path is notably less forgiving of heavy customisation. Before writing a rule, ask whether configuration can achieve it. The most stable IIQ deployments I have seen were not the cleverest — they were the most disciplined about staying close to out-of-the-box behaviour and customising only where there was no alternative.

IdentityIQ rewards operators who respect its pipeline: clean authoritative data, strong correlation, correctly sequenced refresh, resilient provisioning, and minimal bespoke logic. None of that is exotic. All of it is the difference between a platform you trust and one you firefight.