Aggregation in SailPoint: The Complete Guide to IdentityIQ Data Collection
Aggregation in SailPoint is the process of importing accounts, groups, and entitlements from connected applications into IdentityIQ for centralized identity governance. It creates accurate Identity Cubes that support access reviews, provisioning, compliance, and reporting. Understanding aggregation is essential for configuring connectors, troubleshooting identity data, and managing enterprise access efficiently. Professionals seeking SailPoint Certification Training in Hyderabad learn aggregation as a core skill for real-world IdentityIQ implementation and interviews. Mastering this concept helps build secure, compliant, and scalable identity governance solutions.
★★★★★
4.9/5 rated by 1329+ students · Google Verified
Table of Contents
What is Aggregation in SailPoint?
Aggregation in SailPoint is the scheduled process of collecting identity-related data from a connected application and importing it into IdentityIQ. During aggregation, IdentityIQ connects to a target system through a connector, reads the raw account and entitlement records, and stores them as structured objects it can govern.
Think of aggregation as IdentityIQ asking each application a simple question: “Who has an account here, and what can they do?” The answer is captured as account objects, which are then linked to the people they belong to. Without aggregation, IdentityIQ would be an empty shell with no knowledge of the access that actually exists across your estate.
The data aggregation brings in two critical structures. The first is the Identity Warehouse, the central repository that holds every account and entitlement IdentityIQ knows about. The second is the Identity Cube, a 360-degree view of a single person that combines all of their accounts, roles, and entitlements across every aggregated application. Identity governance and administration, as defined by frameworks from bodies like NIST, depends on exactly this kind of consolidated, trustworthy identity data.
Aggregation in SailPoint
How Aggregation Works in SailPoint IdentityIQ
Aggregation in SailPoint IdentityIQ is driven by an aggregation task that runs against one or more applications. The task orchestrates a sequence of steps, each handled by a specific component of the platform. Understanding this flow is the difference between blindly clicking “run” and actually knowing what happens under the hood.
The aggregation workflow generally follows these steps:
- Connector negotiation. IdentityIQ uses the application’s configured connector to establish a connection to the target system, whether that is Active Directory, a database, an ERP, or a cloud service.
- Account read. The connector iterates over accounts in the source system and returns them as raw resource objects containing attributes such as username, department, status, and group memberships.
- Correlation. Each account is matched to an existing identity using correlation rules or configuration, so IdentityIQ knows which person the account belongs to.
- Object build. Matched accounts are stored as Link objects attached to the correct Identity, and entitlements are recorded against the account.
- Cube update. The affected Identity Cubes are refreshed so the person’s aggregated view reflects the newly imported data.
The connector layer is where a lot of the real-world complexity lives. SailPoint ships dozens of out-of-the-box connectors, and each behaves slightly differently. If you want a deeper view of the options available, our breakdown of the SailPoint connectors list and setup process walks through the most common integrations and how they are configured. The connector framework is also documented in depth in SailPoint’s own developer reference.
Aggregation also sits within the broader IdentityIQ architecture. If you are still forming a mental model of how the warehouse, cubes, and task engine fit together, our guide to SailPoint IdentityIQ architecture gives the full picture that aggregation plugs into.
Why Aggregation is Important in Identity Governance
Aggregation is important because it produces the single source of truth that every other governance activity relies on. Access certifications, policy violations, role mining, provisioning, and audit reporting all read from the aggregated data. If aggregation is stale or incomplete, every downstream decision inherits that error.
Consider a quarterly access review. A manager is asked to confirm whether each team member still needs their current access. That review is only meaningful if the entitlements shown were aggregated recently and correlated correctly. Aggregate too infrequently, and reviewers approve access that was already removed or miss access that was quietly granted. Aggregation frequency is therefore a compliance control, not just a technical setting.
The stakes are rising as enterprises expand. The global identity and access management market continues to grow rapidly, according to industry analysis from Grand View Research, driven by cloud adoption, regulatory pressure, and the sheer number of systems each organisation runs. More systems mean more accounts to aggregate and more places for ungoverned access to hide.
Standards-based access control frameworks such as NIST SP 800-53 expect organisations to review and manage access continuously. Aggregation is the mechanism that makes that continuous visibility possible inside SailPoint.
Types of Aggregation in SailPoint
SailPoint supports several types of aggregation, each targeting a different category of data. Configuring the right combination for each application is a core skill.
- Account Aggregation. The most common type. It reads individual user accounts and their attributes from the target application and links them to identities. This is what populates most of the Identity Warehouse.
- Group Aggregation. Reads the groups, roles, or organisational units defined in the source system. Group aggregation is often run before account aggregation so that entitlement definitions exist before accounts reference them.
- Entitlement Aggregation. Captures the fine-grained permissions attached to accounts, such as security groups, roles, or database privileges. Rich entitlement data is what makes access certification and separation-of-duties analysis meaningful.
Beyond the category of data, aggregation is also classified by how much data it reads on each run. That distinction, full versus delta, is important enough to deserve its own section.
Full Aggregation vs Delta Aggregation
Full aggregation reads every account in the target system on every run. Delta aggregation reads only the accounts that changed since the last run. Both have a place, and choosing between them is a balance of accuracy against performance.
Full aggregation is thorough and self-correcting. Because it reads everything, it will always catch accounts that were deleted, missed, or altered outside of IdentityIQ. The trade-off is cost: on a system with hundreds of thousands of accounts, a full aggregation can take hours and place heavy load on both IdentityIQ and the source.
Delta aggregation is fast and lightweight because it only processes changes, but it depends on the source system reliably reporting what changed. Not every connector supports delta, and delta runs can drift over time if change tracking misses events. A common enterprise pattern is frequent delta aggregations during the day with a scheduled full aggregation overnight or weekly to reset the baseline.
|
Aspect |
Full Aggregation |
Delta Aggregation |
Identity Refresh |
|
What it reads |
All accounts from the source |
Only changed accounts since last run |
No source read; recalculates existing data |
|
Data source |
External application |
External application |
IdentityIQ internal data |
|
Speed |
Slowest |
Fast |
Varies by rule complexity |
|
Primary purpose |
Complete, accurate import |
Frequent lightweight updates |
Apply roles, policies, and correlation logic |
|
Detects deletions |
Yes |
Depends on connector support |
No |
|
Typical schedule |
Nightly or weekly |
Hourly or intraday |
After aggregation or on policy change |
Aggregation Process Flow Explained
To troubleshoot aggregation effectively, you need a clear mental model of the process flow. Here is the sequence that runs each time an aggregation task executes against an application.
- Task initialisation. The scheduler or an administrator launches the aggregation task, which loads the target application’s configuration and connector settings.
- Connection and reading. The connector authenticates to the source and begins streaming account records, applying any configured filters so only relevant accounts are pulled.
- Attribute mapping. Raw source attributes are mapped to IdentityIQ application schema attributes, transforming vendor-specific fields into a consistent internal format.
- Correlation. Each account is matched to an identity using the application’s correlation configuration or a custom correlation rule.
- Link creation or update. A Link object representing the account is created on the matched identity, or an existing Link is updated with new attribute values and entitlements.
- Customization rules. Optional aggregation rules, such as a customization or merge rule, run to transform or enrich data before it is persisted.
- Persistence and cube refresh. Changes are committed to the Identity Warehouse and affected Identity Cubes are updated so the aggregated view is current.
Rules and workflows can hook into several of these stages, giving developers precise control over how data is interpreted. This is where BeanShell and Java logic frequently appear, and it is a favourite area for technical interviewers to probe.
Identity Refresh vs Aggregation
Aggregation and identity refresh are often confused because both keep identity data current, but they do fundamentally different jobs. Aggregation brings new data in from external systems. Identity refresh recalculates existing data that is already inside IdentityIQ.
During an identity refresh, IdentityIQ re-evaluates each identity against roles, policies, and correlation logic. It assigns detected and required roles, checks for separation-of-duties violations, updates manager relationships, and can trigger provisioning based on the results. Crucially, refresh does not connect to any source application; it works entirely with data that aggregation already imported.
The practical relationship is sequential. You aggregate first to load the latest account and entitlement data, then refresh to apply governance logic on top of it. Running refresh without a recent aggregation means you are applying rules to potentially stale data, which is a common cause of confusing results in test environments.
Aggregation vs Provisioning in SailPoint
Aggregation and provisioning move data in opposite directions. Aggregation reads access from applications into IdentityIQ. Provisioning pushes access changes from IdentityIQ out to applications. Together they form the read and write halves of identity lifecycle management.
When a new employee joins, a joiner workflow might provision accounts into several systems. Later, aggregation reads those systems and confirms the accounts exist and match what IdentityIQ expected. When the two disagree, IdentityIQ can detect the discrepancy, which is how ungoverned or out-of-band access gets flagged. If you want to see how these processes are orchestrated differently across products, our comparison of IdentityIQ and IdentityNow workflows is a useful companion read.
|
Process |
Direction |
Connects to source? |
Primary goal |
|
Aggregation |
Source to IdentityIQ (read) |
Yes |
Import accounts and entitlements |
|
Provisioning |
IdentityIQ to source (write) |
Yes |
Grant, change, or revoke access |
|
Correlation |
Internal matching |
No |
Link accounts to the right identity |
|
Identity Refresh |
Internal recalculation |
No |
Apply roles, policies, and detection logic |
Aggregation vs Correlation
Correlation is a step within aggregation, not a separate competing process, but it is worth isolating because so many aggregation problems are really correlation problems. Aggregation reads an account; correlation decides which person that account belongs to.
Correlation works by matching an attribute on the incoming account, such as an employee ID or email address, to an attribute on an existing identity. When correlation succeeds, the account is linked to the correct Identity Cube. When it fails, the account becomes uncorrelated and shows up as orphaned or unmatched, which pollutes certifications and reports.
Well-designed correlation rules are the quiet heroes of a healthy SailPoint deployment. Poorly designed ones create duplicate identities, orphan accounts, and hours of cleanup. Because entitlements flow through correlated accounts into roles, correlation quality also directly affects role-based access control in IdentityIQ.
Common Aggregation Errors and Troubleshooting
Even well-configured aggregation tasks fail, and the ability to diagnose them quickly is a hallmark of an experienced engineer. Most issues fall into a handful of recognisable categories.
|
Symptom |
Likely cause |
Resolution |
|
Connection timeout or auth failure |
Expired credentials, network or firewall block |
Verify service account, rotate credentials, confirm host and port reachability |
|
Accounts not correlating |
Correlation attribute missing or mismatched |
Review correlation config and source data quality; adjust the correlation rule |
|
Aggregation runs but no updates appear |
Delta tracking missed changes or filter too narrow |
Run a full aggregation to reset baseline; review iterate filters |
|
Task extremely slow |
Large dataset, unindexed queries, heavy rules |
Enable delta, optimise rules, tune database and thread settings |
|
Entitlements missing |
Group aggregation not run or schema gaps |
Run group aggregation first; confirm entitlement attributes in schema |
|
Duplicate identities created |
Correlation failing on unique identifier |
Fix correlation logic and merge duplicates carefully |
When a task fails, the aggregation task result and the IdentityIQ logs are your first stop. They record which account was being processed when the error occurred, which usually points straight at the offending record or rule. SailPoint’s official IdentityIQ documentation is the authoritative reference for connector-specific error codes and task settings.
Best Practices for SailPoint Aggregation
Reliable aggregation is the product of good habits, not luck. The practices below consistently separate stable deployments from fragile ones.
|
Recommended Practice |
Benefit |
Business Impact |
|
Run group aggregation before account aggregation |
Entitlement definitions exist before accounts reference them |
Accurate entitlement data for certifications |
|
Use delta aggregation for frequent runs |
Lower load and faster completion |
More current data without performance cost |
|
Schedule a periodic full aggregation |
Catches deletions and drift delta can miss |
Higher data integrity and audit confidence |
|
Validate correlation on a sample first |
Prevents mass orphan or duplicate creation |
Clean identity data and less rework |
|
Keep aggregation rules lean and tested |
Faster runs and fewer failures |
Predictable, maintainable governance pipeline |
|
Monitor task results and alert on failures |
Problems are caught before certifications |
Compliance deadlines are protected |
|
Document each application’s aggregation config |
Knowledge is not locked in one person’s head |
Faster onboarding and safer handovers |
Performance Optimization Tips for Aggregation
As enterprises scale to hundreds of applications and millions of accounts, aggregation performance becomes a genuine engineering concern. A few targeted optimisations deliver most of the improvement.
- Prefer delta where supported. Reading only changes is the single biggest lever for reducing run time on large systems.
- Tune thread counts. Increasing aggregation threads can speed processing, but too many will overwhelm the source system or the IdentityIQ database. Test to find the sweet spot.
- Filter at the source. Use connector-side filters so IdentityIQ never receives accounts it does not need to govern, such as service or system accounts handled elsewhere.
- Optimise custom rules. Aggregation rules run once per account. A slow rule multiplied across a million accounts becomes a major bottleneck. Cache lookups and avoid unnecessary queries.
- Stagger schedules. Avoid running many heavy aggregations simultaneously. Spread them across off-peak windows to protect database performance.
- Index correlation attributes. Ensure the attributes used for correlation are indexed so matching does not degrade as identity volume grows.
Performance tuning is also where cloud-native governance differs from on-premises IdentityIQ. If your organisation is evaluating the move, our overview of SailPoint Identity Security Cloud explains how aggregation and data collection are handled on the Atlas platform.
Common Challenges Beginners Face
Knowing the typical hurdles in advance makes them far easier to overcome
- Concept overload: identity, account, entitlement, role and policy can blur together at first. Slow down and learn each clearly.
- Fear of scripting: beginners often overestimate how much code is involved. Most rules are short and pattern-based.
- Lack of practice environment: theory without hands-on labs does not stick. Practical exposure is essential.
- Terminology between products: IIQ and ISC use slightly different terms for similar ideas.
- Interview readiness: turning knowledge into confident answers. Reviewing SailPoint interview questions and answers early helps you study with the end goal in mind.
Real-World Aggregation Use Cases
Aggregation is not an abstract exercise; it underpins concrete business outcomes every day. A few representative scenarios show why teams invest so heavily in getting it right.
Audit and compliance readiness. Before an audit, an organisation runs full aggregation across in-scope systems to guarantee reviewers see current access. Aggregated data feeds certification campaigns that produce the evidence auditors demand.
Joiner-mover-leaver accuracy. When employees change roles or leave, aggregation confirms that provisioning and deprovisioning actually happened in the target systems, closing the loop on lifecycle management and reducing standing risk from lingering access.
Mergers and integrations. When a company acquires another, aggregating the acquired estate into IdentityIQ is often the first step toward unified governance. Complex enterprise applications, such as SAP landscapes, need careful connector work; our guide to SailPoint integration with SAP and enterprise applications covers that scenario in detail.
Detecting rogue access. Because aggregation reveals what access truly exists, it exposes accounts and entitlements granted outside approved processes. This out-of-band detection is one of the strongest security arguments for frequent aggregation.
Why Aggregation is One of the Most Important Processes in SailPoint IdentityIQ
If you strip identity governance down to its essentials, aggregation is the process everything else stands on. Its importance shows up across five dimensions.
Security. You cannot secure access you cannot see. Aggregation continuously surfaces every account and entitlement, turning invisible risk into governable data. Frequent aggregation shrinks the window in which unauthorized access can persist undetected.
Compliance. Regulations and frameworks expect organisations to demonstrate who has access to sensitive systems and to review that access regularly. Aggregated, current data is what makes certification campaigns and audit reports credible rather than theatrical.
Identity accuracy. Correlated aggregation builds complete Identity Cubes, giving each person a single accurate profile. Accurate identities are the foundation for role assignment, policy evaluation, and clean provisioning decisions.
Access governance. Certifications, policy checks, and role mining all read aggregated data. The richness and freshness of that data directly determines how effective governance can be. Weak aggregation quietly undermines every governance control above it.
Operational efficiency. Automated, well-tuned aggregation replaces manual access reviews and spreadsheet reconciliation with a repeatable pipeline. That efficiency scales governance to hundreds of applications without proportional headcount, which is the entire promise of a modern identity governance program.
Ready to go deeper than theory? Structured, hands-on SailPoint training in Hyderabad lets you configure aggregation tasks, write correlation rules, and troubleshoot real failures in a lab environment, which is where genuine expertise is actually built.
Key Takeaways
- Aggregation in SailPoint reads accounts, groups, and entitlements from connected applications and loads them into the Identity Warehouse and Identity Cubes.
- Full aggregation reads everything and self-corrects; delta aggregation reads only changes and is far faster, so most enterprises combine both.
- Correlation runs inside aggregation and determines which identity each account belongs to; most aggregation problems are really correlation problems.
- Aggregation reads data in, while provisioning writes changes out, and identity refresh recalculates existing data without touching any source.
- Frequent, well-tuned aggregation is the foundation of accurate certifications, credible audits, and continuous security across the enterprise.
Conclusion
Aggregation in SailPoint is the process that turns scattered, invisible access into governed, trustworthy identity data. It reads accounts, groups, and entitlements from every connected system, correlates them to real people, and builds the Identity Warehouse and Identity Cubes that certifications, provisioning, and audits depend on. Get aggregation right and the rest of identity governance becomes achievable; get it wrong and every downstream control inherits the flaw.
Because it sits at the foundation of security, compliance, identity accuracy, and operational efficiency, aggregation deserves deep, deliberate study rather than surface familiarity. Learn the types, master correlation, understand how full and delta runs complement each other, and practise diagnosing failures until it becomes second nature.
If you are serious about building enterprise identity expertise, the fastest path is structured, hands-on practice. The SailPoint Masters program at Brolly Academy is designed to take you from foundational concepts through real aggregation, correlation, and provisioning work in a guided lab environment, so you graduate ready for genuine enterprise deployments. Pair this guide with our SailPoint interview questions and answers and the full IIQ curriculum to round out your preparation.
FAQ
- What is aggregation in SailPoint?
Aggregation in SailPoint collects accounts, groups, and entitlements from connected systems into IdentityIQ for centralized identity governance. - What is the difference between full and delta aggregation?
Full aggregation imports all accounts, while delta aggregation imports only the changes since the previous run. - Is correlation the same as aggregation?
No, aggregation imports data, whereas correlation matches imported accounts to the correct identities. - What is the difference between aggregation and provisioning?
Aggregation reads data into IdentityIQ, while provisioning sends access changes from IdentityIQ to target systems. - How is identity refresh different from aggregation?
Aggregation imports external data, whereas identity refresh recalculates identities using existing IdentityIQ data. - What are the main types of aggregation in SailPoint?
The main types are account aggregation, group aggregation, and entitlement aggregation. - Why does my SailPoint aggregation run but import no changes?
This usually occurs because no new changes are detected or the connector/filter configuration is incorrect. - How often should aggregation be scheduled?
Aggregation should be scheduled based on business needs, commonly using frequent delta runs and periodic full runs. - What causes orphan accounts after aggregation?
Orphan accounts occur when imported accounts cannot be matched to any identity during correlation. - Do I need Java to work with SailPoint aggregation?
No, Java is optional for basic configuration but useful for advanced customization and rule development.
SailPoint Trainer
SailPoint Masters Editorial Team | 15+ Articles Published
We specialize in SailPoint Certification Training in Hyderabad, helping aspiring professionals and IT experts develop in-demand Identity and Access Management (IAM) skills. Our training covers SailPoint IdentityIQ, Identity Security Cloud, certification preparation, real-world projects, and career guidance to support success in cybersecurity and identity governance careers.
Share