SailPoint aggregation
Aggregation is how IdentityIQ pulls accounts and entitlements from connected systems into its object model.
Aggregation is the read process. IdentityIQ connects to an application and pulls in its accounts (account aggregation) or its groups and permissions (group aggregation). The data is stored as Links on identities and as Managed Attributes, then correlation and identity refresh make sense of it.
- Aggregation reads data in; provisioning writes it out
- Account aggregation loads accounts; group aggregation loads entitlements
- Correlation links accounts to identities during or after aggregation
- Delta aggregation reads only what changed, for speed
- Refresh after aggregation recomputes roles and policy
Aggregation is how account and entitlement data from external systems enters SailPoint. It is the inbound foundation of governance, you cannot govern access you have not aggregated, and getting it right (and keeping it current) is a prerequisite for everything else the platform does.
Two kinds of aggregation
- Identity aggregation, reads the authoritative source (usually HR) to create and update identity cubes.
- Account aggregation, reads a target application’s accounts and entitlements into the warehouse as Links.
The aggregation flow
- A scheduled task starts for a configured application.
- The connector authenticates and reads accounts and entitlements per the mapped schema.
- Data is loaded into the warehouse (entitlement values may be promoted to Managed Attributes).
- Correlation attaches each account to the correct identity.
- An optional identity refresh recomputes cubes, roles and policy.
Full versus delta aggregation
A full aggregation reads the entire population each run, simple but expensive at scale. A delta (incremental) aggregation reads only what changed, dramatically reducing load on large sources. Use delta where the connector supports it, and run periodic full aggregations to catch anything delta misses.
Correlation: the make-or-break step
Aggregation is only useful if accounts correlate to identities. An account that fails to correlate becomes an orphan, owned by no one and outside governance, which is exactly the risk you are trying to eliminate. Reliable correlation logic on a stable key, plus monitoring for uncorrelated accounts, is essential.
Aggregate, then refresh
A classic mistake is aggregating without refreshing: accounts update, but roles and policy never re-evaluate, so the environment silently drifts out of date. The standard rhythm is authoritative aggregation, target aggregation, then identity refresh, on a schedule that matches the business’s tolerance for staleness.
Common pitfalls
- Aggregating without a following refresh, leaving governance stale.
- Weak correlation producing orphan accounts.
- Full aggregation on huge sources where delta would be far cheaper.
Practice challenge
3 questionsQ1Aggregation is the process of?
Reading data into IdentityIQ. Aggregation reads accounts and entitlements in; provisioning writes out.
Reading data into IdentityIQ. Aggregation reads accounts and entitlements in; provisioning writes out.
Q2Groups and permissions are loaded by?
Group aggregation. Group (entitlement) aggregation loads Managed Attributes.
Group aggregation. Group (entitlement) aggregation loads Managed Attributes.
Q3Reading only what changed since last run is?
Delta aggregation. Delta (incremental) aggregation reads only changed accounts for speed.
Delta aggregation. Delta (incremental) aggregation reads only changed accounts for speed.
Frequently asked questions
What does the term aggregation refer to in SailPoint?
What is another point to note about aggregation?
What else is worth knowing about aggregation?
What tends to go wrong with aggregation?
Want this taught live, with job support?
SailPoint Training is delivered live by working practitioners, with certification prep and placement support.
See SailPoint Training →