How SailPoint ISC Transforms Application Data into Reliable Identities

When working in IAM, it's easy to focus on high-level goals like provisioning or certification — but none of that works until you have good identity data in place.

After connecting my Google Cloud-hosted MySQL database to SailPoint Identity Security Cloud (ISC) using the Virtual Appliance, I wanted to understand:
What really happens after aggregation?
How does an account from an external application turn into a governed identity inside SailPoint?

So I decided to walk through that entire flow — and share it here.

---

Where It Starts: The Source

Every identity starts in a source system — for me, that was a MySQL database acting as an authoritative store. This source held user data like names, email addresses, departments — all the pieces needed to form a user record.

I connected this DB to ISC using the JDBC connector via the Virtual Appliance.

Once the connection was tested, it was time to aggregate accounts.

Aggregation: Pulling in Raw Accounts

Account aggregation is ISC's way of saying:
"Let me go fetch account data from this source and see what I can do with it."

Behind the scenes, the VA runs the SQL query I provided:

Each row becomes an account object — not yet an identity, but a potential building block for one.

Correlation: Turning Accounts into Identities

This is where things get interesting.

Once ISC has accounts, it needs to figure out whether:

• It should create a new identity

• Or link to an existing one

That logic is driven by the Identity Profile, which defines:

• The correlation rule (e.g., match on email or employee ID)

• Which attributes from the account map to identity fields

• Which source takes priority if multiple sources send the same user

In my case, I used email as the correlation key. If an email matched, ISC linked the account to an existing identity. If not, it created a new one.

Transforms: Cleaning Up the Data

Before account data becomes part of the identity, it runs through transforms.

This is where I standardized things:

• Concatenated first and last name into a lowercase username

• Lowercased email addresses

• Mapped department codes to full department names

It might seem minor, but clean, consistent data is what makes access policies and provisioning logic actually work.

Identity Created: Inside the Identity Cube

Once everything is mapped and transformed, ISC creates an Identity Object in the Identity Cube.

Each identity includes:

• Mapped attributes (name, email, title, dept)

• Linked accounts from the source

• Entitlements (if pulled)

• Lifecycle state (like Joiner, Active, Terminated)

At this point, that identity can be governed — you can apply policies, start certifications, assign access, and more.

Why This Flow Is So Important

You can’t govern what you haven’t defined.
You can’t certify what you haven’t correlated.
And you definitely can’t automate provisioning on bad data.

Most IAM challenges don’t come from bad provisioning logic — they come from incomplete, inconsistent, or unlinked identity data.

That’s why understanding how aggregation, correlation, and transforms work together is so important. It’s not just “syncing data.” It’s creating the foundation of trust your entire IAM system runs on.