Ask a SailPoint candidate what correlation is and most will say "it links accounts to identities". That is true and it is not enough. The follow-up question in a real SailPoint IdentityIQ interview is almost always the same one: which logic does IdentityIQ try first, and what happens when every layer of it fails? Candidates who can narrate that sequence get shortlisted. Candidates who cannot are the reason enterprises end up with thousands of accounts attached to nobody.
Quick answer: Correlation in SailPoint IdentityIQ (IIQ) is the matching process that decides which Identity Cube an aggregated application account belongs to. During account aggregation, IdentityIQ evaluates correlation logic in a fixed order — a correlation rule first, then the correlation configuration that pairs account attributes with identity attributes, then default correlation on the application's display attribute. If none of the three produce a match, the account is left uncorrelated or a new identity is created for it, which is exactly how orphan accounts appear. Correlation is configured per application on the Correlation tab and can be repaired afterwards through Identities > Identity Correlation.
This guide walks that pipeline in the order IdentityIQ runs it, using the vocabulary interviewers and auditors use. It is written from the material we teach in our live online SailPoint IIQ course, where correlation is not a bullet on a slide but something you misconfigure on purpose, watch break, and then repair.
What is correlation in SailPoint IIQ?
Correlation in SailPoint IdentityIQ (IIQ) is the process of matching an application account to the correct IdentityIQ identity. SailPoint's official IdentityIQ documentation describes it as how IdentityIQ maps data from a source system onto the authoritative identities already stored in IdentityIQ, so that one person's scattered accounts resolve to one record.
Take a single employee at an Indian bank. Her Active Directory login is p.kulkarni, her SAP user ID is P004831, her Salesforce account is her work email, and her legacy ticketing account was created eight years ago as pkulkarni2. To the four systems, those are four unrelated users. Correlation is the logic that tells SailPoint IdentityIQ all four belong to one person — and therefore that her manager reviews all four together at certification time, and all four are revoked on the day she leaves.
Why this is a governance problem, not a data problem: an access certification can only review what is attached to an identity. Every account that fails to correlate is access that no manager is ever asked to approve. Correlation quality is therefore the upper limit on how complete your compliance evidence can be.
The record those accounts attach to is the Identity Cube — explained in full in our guide to the SailPoint IIQ Identity Cube. The wider setup around it, including connectors and schema, is covered in SailPoint IIQ application onboarding explained. This post goes deeper on the one step both of those posts summarise in a sentence.
What is the difference between correlation and aggregation in SailPoint IIQ?
Aggregation is the task that reads accounts out of an application; correlation is the matching logic that runs inside it. In SailPoint IdentityIQ you never schedule a "correlation task" — you schedule an account aggregation, and correlation is evaluated for each account as it arrives. Identity refresh then finalises the links and recalculates roles, policy and risk.
| Process | What it is | When it runs |
|---|---|---|
| Aggregation | A scheduled task that reads accounts and entitlements from one application into IdentityIQ | Scheduled per application |
| Correlation | Matching logic evaluated for each incoming account to decide which identity it belongs to | Inside aggregation, per account |
| Identity refresh | A task that finalises links and recalculates roles, policies and risk scores on the identity | After aggregation |
Process definitions summarised from SailPoint's official IdentityIQ documentation (documentation.sailpoint.com), reviewed September 2026.
That distinction matters in troubleshooting. If accounts are missing entirely, the problem is aggregation or the connector. If accounts are present but attached to the wrong person or to nobody, the problem is correlation. If the accounts are attached correctly but roles and risk look stale, the problem is refresh. Our guide to SailPoint IIQ jobs — aggregation, refresh and system tasks covers the task layer in detail.
How does SailPoint IIQ decide which identity an account belongs to?
SailPoint IdentityIQ evaluates correlation in three layers and stops at the first one that returns a match: the correlation rule, then the correlation configuration, then default correlation. If all three fail, the account is left uncorrelated or a new identity is created for it. Knowing this precedence is the single most useful thing a learner can carry into an IIQ interview.
Correlation rule — BeanShell, runs first
If a correlation rule is attached to the application, SailPoint IdentityIQ runs it before anything else. The rule receives the incoming account and returns a map identifying the identity to link to. Whatever it returns wins.
Debug clue: a rule that silently returns null hands control to the next layer — it does not stop correlation.Correlation configuration — attribute pairs, runs second
If no rule matched, IdentityIQ applies the attribute pairs defined on the application's Correlation tab — for example account employeeId matched to identity employeeNumber. This is the layer most enterprises actually rely on.
Debug clue: this layer is only as good as the data. A blank employee ID cannot match anything.Default correlation — the silent one, runs last
If the configuration also returns nothing, SailPoint IdentityIQ falls back to default correlation, which matches the application's display attribute value against existing identity names. Nobody configures this layer, which is why nobody suspects it.
Debug clue: unexplained wrong links or unexpected new identities are usually default correlation doing its job quietly.No match — uncorrelated account or a new identity
When every layer fails, the account either sits uncorrelated on the application or causes IdentityIQ to create an identity from the account itself. Which of the two happens depends on how the application is configured.
Debug clue: a target application wrongly flagged authoritative turns every failed match into a duplicate person.Precedence order as documented in the SailPoint Compass community wiki on correlation rule, correlation configuration and default correlation, and in SailPoint Developer Community IIQ discussion threads, reviewed September 2026.
Correlation rule vs correlation configuration — which should you use?
Use correlation configuration when a clean attribute on the account matches a clean attribute on the identity, and write a correlation rule only when the values need transformation or conditional logic before they can match. Reaching for a rule first is the most common design mistake beginners make on real SailPoint IdentityIQ projects.
| Correlation configuration | Correlation rule | |
|---|---|---|
| What it is | Attribute pairs set on the application's Correlation tab | BeanShell logic attached to the application |
| Coding needed | None — interface configuration | Yes — BeanShell, Java-like syntax |
| Precedence | Runs second | Runs first, overrides the configuration |
| Best for | Clean, consistent keys such as employee ID | Prefix stripping, case or format fixes, fallback attributes, conditions |
| Maintenance cost | Low — visible to any administrator | Higher — a code artefact that needs review and testing |
A realistic example: the HR system stores employee numbers as 00048312 while Active Directory stores them as 48312. No attribute pair will ever match those two values, so a correlation rule strips the leading zeros before comparing. That is a legitimate rule. Matching employeeId to employeeNumber when both are already clean is not — it is configuration work wearing a developer's badge.
Correlation rules sit in the same family as aggregation, provisioning, connector and schema rules, all covered in our guide to SailPoint IIQ rules and BeanShell. If you are weighing up how much coding an IAM role really demands, does SailPoint require coding breaks it down role by role.
How do you configure correlation on an application in SailPoint IIQ?
Correlation is configured on the Correlation tab of the application definition in SailPoint IdentityIQ, where you pair each account attribute with the identity attribute it should match against. The same tab is where manager correlation is defined, so that an account's manager value resolves to another identity rather than staying a text string.
Pick a stable correlation key
Employee ID beats email, and email beats display name. The best key is the one that never changes when someone marries, transfers or is rehired.
Pair account attribute to identity attribute
Each row maps one attribute on the account schema to one attribute on the Identity Cube. Multiple pairs can be defined for fallback matching.
Use conditions for accounts with no identifying data
SailPoint's documentation gives the example of a Unix root account, which carries nothing personal — a condition assigns it based on application ownership instead.
Configure manager correlation separately
Manager correlation resolves the manager attribute on an account to an actual identity, which is what makes manager access certifications possible.
One ordering rule outranks all of this: the authoritative source must be aggregated before any target application. A target account cannot correlate to an Identity Cube that does not exist yet, and aggregating Active Directory into an empty IdentityIQ is how projects generate thousands of uncorrelated accounts on day one.
Reading about correlation is not the same as breaking it and fixing it
Attend a free 60-minute live demo before you decide — no payment, no commitment. Ask the trainer to show an account failing all three correlation layers, and judge the teaching on that.
What is an uncorrelated or orphan account in SailPoint IIQ?
An uncorrelated account in SailPoint IdentityIQ is an aggregated application account that correlation logic could not match to any Identity Cube. SailPoint's IdentityIQ documentation lists two of the most common reasons plainly: people who no longer work for the enterprise but still hold accounts, and mismatched or redundant accounts created at different times under variations of someone's name.
Blank or mismatched keys
The correlation attribute is empty on the account, or formatted differently across systems — leading zeros, domain prefixes, upper case versus lower case.
Genuinely ownerless accounts
Accounts belonging to leavers, contractors whose records were purged, or duplicates created years apart. These are real audit findings, not configuration errors.
Service and non-personal accounts
Built-in administrator, service and guest accounts have no human owner, so standard correlation rules never match them. Every application has some.
Wrong sequence
The target application was aggregated before the authoritative HR source ran, so there were no identities to correlate against at the time.
The compliance consequence is the reason interviewers care. Orphaned accounts are a standing finding in SOX and RBI audits at Indian banks and GCCs, because an account with no owner is access nobody reviews and nobody revokes. Where those reviews happen is covered in our SailPoint IIQ access certification guide.
How do you fix uncorrelated accounts in SailPoint IIQ?
SailPoint IdentityIQ provides a manual repair path at Identities > Identity Correlation, where you select an application, retrieve every uncorrelated account on it, and merge selected accounts into a target identity. According to SailPoint's IdentityIQ documentation, manual correlation creates a permanent link — the account stays attached even if the source attribute values later change.
That permanence is a double-edged tool. It is exactly what you want for a legacy account whose employee ID will never be populated, and exactly what you do not want as a substitute for fixing broken correlation logic. The sequence practitioners follow is to repair the configuration first and correlate by hand only what genuinely cannot be matched by rule.
The re-run trap that costs an afternoon: after fixing correlation logic, a normal optimised aggregation may skip accounts it considers unchanged, so the fix appears not to have worked. Threads on the SailPoint Developer Community repeatedly trace "my correlation rule does not correlate uncorrelated accounts" back to this. Re-run the aggregation with optimisation disabled.
Service accounts deserve a deliberate decision rather than a repair. A common enterprise pattern discussed on the SailPoint Developer Community is to correlate all non-personal accounts for an application to a single designated non-personal identity, so they are owned, visible and certifiable instead of sitting in the uncorrelated pile forever. Leaving them uncorrelated is what turns a manageable exception list into an audit backlog.
How is correlation different in SailPoint Identity Security Cloud (ISC)?
SailPoint Identity Security Cloud (ISC) keeps the same concept but moves the configuration: correlation is defined on the source as criteria pairing an account attribute with an identity attribute drawn from the identity profile, rather than through an IdentityIQ application Correlation tab and a BeanShell rule. The identity profile is the ISC equivalent of the authoritative-source definition.
Two practical differences matter to a learner. ISC leans on configured criteria rather than code, so the BeanShell correlation rule has no direct day-to-day equivalent for most sources. And organisations licensed for SailPoint application onboarding can see suggested attribute pairings ranked by correlation percentage, with the order of criteria optimised automatically — a convenience IdentityIQ administrators do not get.
The concept transfers cleanly in both directions, which is why dual-platform job descriptions are increasingly common. Our comparison of SailPoint IdentityIQ vs IdentityNow (now ISC) covers which to learn first, and IIQ to ISC migration skills covers the dual-skill path. SailPoint Academy is launching a live online SailPoint ISC (Identity Security Cloud) course — the waitlist is open on WhatsApp.
What do interviewers ask about SailPoint correlation?
Correlation is one of the most reliably tested SailPoint IdentityIQ interview topics, and the questions cluster around precedence, orphan accounts and troubleshooting rather than definitions. Interviewers at consulting firms, IT services companies and BFSI GCCs use it because a candidate who has only watched videos can define correlation but cannot debug it.
"What is a correlation rule, and when would you write one instead of using attribute-based correlation?"
Answer with the transformation example, not the definition. Format mismatch justifies a rule; a clean key does not.
"In what order does IdentityIQ evaluate correlation?"
Rule, then configuration, then default correlation on the display attribute, then no match. Name all four outcomes.
"How do you debug orphan accounts after an aggregation run?"
Confirm the authoritative source ran, inspect the correlation key on a failing account, correct the mapping, re-run aggregation without optimisation.
"Aggregation produced duplicate identities — what went wrong?"
Usually a target application flagged as authoritative, so every failed match created a person instead of an exception.
"How would you handle service accounts that never correlate?"
Correlate them to a designated non-personal identity so they remain owned and certifiable, rather than leaving them uncorrelated.
"What is manual correlation and when is it appropriate?"
Identities > Identity Correlation, creating a permanent link — appropriate for genuine exceptions, never as a substitute for fixing logic.
Full question banks with model answers are in our SailPoint IIQ interview questions guide and the scenario-based SailPoint interview questions collection, which covers the aggregation and correlation scenarios in more depth.
Where does correlation sit in a structured SailPoint IIQ course?
Correlation is taught inside Module 3, Application Onboarding, of SailPoint Academy's 14-module SailPoint IdentityIQ curriculum, and is exercised again in Module 4, SailPoint Jobs, and Module 6, Application Rules. It is configured in Module 3, observed running in Module 4, and coded in Module 6 for the applications that need a rule.
That spread is deliberate. A course that taught correlation as one slide would leave a learner able to define it and unable to repair it — which is precisely the gap interviewers probe. The full sequence is on our 14-module IIQ curriculum page: IAM Overview, SailPoint Architecture, Application Onboarding, SailPoint Jobs, Configuration File, Application Rules, Role Management, Policy Management, Risk Score, Groups/Workgroups/Population, Access Certification, Lifecycle Events, Custom Workflow, and Quick Link & Reporting.
Naukri listed 6,164 vacancies mentioning SailPoint across India in September 2026, including 1,026 in Hyderabad and Secunderabad. Aggregation, correlation and certification appear in the majority of those job descriptions, because they are the three things an auditor actually inspects. Pay bands by role are mapped in our SailPoint IIQ salary in India 2026 guide, and the progression from analyst to architect is laid out on our IAM career paths page.
Job counts are public Naukri listing totals for the stated search terms on the dates shown. Listing counts fluctuate daily and include duplicate and agency postings. These are market indicators, not guarantees of employment.
SailPoint Academy teaches the IIQ program 100% live online over 2 months for Rs. 25,000, with batches capped at 25 students, session recordings in the LMS, hands-on labs, and a lead trainer with 14+ years of enterprise IAM experience. We provide placement assistance and career guidance, and award a SailPoint Academy certificate of completion — not an official SailPoint Technologies certification, which is available only through SailPoint's own Identity University. SailPoint Academy is an independent training provider and is not affiliated with SailPoint Technologies Inc.
Frequently Asked Questions
Break Correlation on Purpose — Then Fix It
SailPoint IIQ training for working professionals — Rs. 25,000, 2 months, all 14 modules, 100% live on Zoom, batch capped at 25, recordings in the LMS. Attend a free 60-minute demo first. No payment. No commitment.