Data flow
How data moves through IdentityIQ: from authoritative sources in, through the warehouse, and out to target systems.
Data flows in from authoritative and target sources via aggregation, is normalized into cubes in the warehouse, and flows back out to targets via provisioning.
- Inbound: aggregation from sources
- Processing: correlation and cube refresh
- Outbound: provisioning to targets
- The warehouse is the hub of all data flow
Data in IdentityIQ moves in two directions around a central hub. It flows inbound from source systems through aggregation, is normalised and correlated into identity cubes in the warehouse, and flows outbound to target systems through provisioning. Almost every operational question, why is this access wrong, why is this identity stale, comes down to understanding where in this flow something went wrong.
Inbound: aggregation
Aggregation is how external reality enters IdentityIQ. Two flavours matter:
- Account aggregation reads accounts and entitlements from a target application (AD, SAP, a database) into the warehouse as Links.
- Identity aggregation reads the authoritative source (usually HR) to create and update identity cubes.
After accounts are read, correlation attaches each account to the correct identity, and optionally an identity refresh recomputes derived data.
Processing: the warehouse as hub
Once inside, data is normalised into the object model and consolidated onto cubes. The refresh engine applies attribute mappings, re-evaluates role assignment, runs policies and fires lifecycle events. The database is the single hub through which all of this passes, which is why its performance and integrity dominate the whole system.
Outbound: provisioning
When a decision is made, birthright assignment, an approved request, a certification revocation, the provisioning engine compiles a plan and pushes the change out through connectors to the real target systems. This closes the loop: what SailPoint believes about access and what the target systems actually enforce are kept aligned.
Keeping data fresh: cadence and delta
Data is only useful if it is current, so aggregation and refresh run on a schedule, commonly the authoritative source nightly, targets on their own cadence, followed by a refresh. To limit load, delta (incremental) aggregation reads only what changed since the last run instead of the full population. Stale data is a silent, corrosive problem: governance decisions made against yesterday's reality are wrong decisions.
A worked trace
Suppose an employee is promoted. Workday records the new title, tonight's identity aggregation brings the change into the cube, the identity refresh re-evaluates role assignment and the new title matches a role whose membership criteria now apply, the provisioning engine grants that role's entitlements through connectors, and the audit trail records the whole chain. Every hop is observable, which is exactly what makes IdentityIQ debuggable.
Common pitfalls
- Aggregating without refreshing, so accounts update but roles and policy never re-evaluate.
- Full aggregation everywhere, when delta would cut load dramatically.
- Unreliable authoritative feeds, which poison every downstream decision.