Identity

A useful way to hold the difference in your head: a person has one identity but many accounts. A single employee might have an Active Directory account, a Workday worker record, a mailbox, an SAP user, a Salesforce login and a dozen SaaS accounts. Each of those is a separate credential on a separate system. SailPoint calls each one a Link and attaches all of them to the one identity through a process called correlation.

• Account (Link): one credential on one application, with its own attributes such as sAMAccountName or employeeNumber.
• Identity (Cube): the person, with a consolidated view of every Link, every entitlement and a set of governed identity attributes.

Governance only becomes possible once you reason about people rather than scattered logins. "Does Priya still need finance access?" is answerable at the identity level; it is almost impossible to answer if all you have is a list of AD accounts with no idea which human each belongs to.

Every identity carries a set of attributes, name, department, title, manager, employee type, location, cost centre, lifecycle status. These are not typed in by hand. They are mapped from an authoritative source, almost always the HR system (Workday, SuccessFactors, SAP HR). The authoritative source is the system of record that decides who exists and what their core attributes are.

Attribute mapping is configured on the identity itself: each identity attribute is populated from a named application attribute, optionally transformed by a rule. For example department on the cube might be mapped from Workday's Cost_Center_Name, and manager resolved by looking up the manager's own identity. Getting this mapping clean is the single most important foundation in any deployment, because roles, lifecycle events and policy all read from these attributes.

IdentityIQ ships with a handful of standard identity attributes and lets you define extended attributes for anything else your organisation governs on, for instance clearanceLevel or contractEndDate. Extended attributes can be marked searchable so they are indexed for fast filtering in certifications and reports; over-marking everything searchable, however, bloats the database and slows refresh, so choose deliberately.

Identities are created and maintained by two tasks working together:

• Identity aggregation reads the authoritative source and creates or updates an identity cube for each worker.
• Identity refresh recomputes derived data on existing cubes, re-running attribute mappings, re-evaluating role assignment, running policies and firing lifecycle events.

The typical cadence is to aggregate the authoritative source on a schedule (often nightly), aggregate target applications, then run an identity refresh so every cube reflects the latest reality. Skipping the refresh is a classic mistake: accounts get aggregated but roles and policy never re-evaluate, so the environment silently drifts out of date.

Identities are not only for employees. Service accounts, shared accounts, RPA bots and machine principals increasingly need governance too. SailPoint models these as identities with an appropriate type so they can be owned, certified and monitored like any other, closing a gap that unmanaged service accounts have historically left wide open.

• Weak correlation logic leaves accounts uncorrelated, so they appear to belong to no one and escape governance. Always define a reliable correlation key such as employeeId, with a sensible fallback.
• Mapping attributes from a non-authoritative source produces conflicting data. Decide which system owns each attribute and map only from there.
• Forgetting the refresh after aggregation leaves roles and policy stale.

Master the identity as a concept and the rest of SailPoint falls into place, because aggregation, provisioning, roles, certifications and policy are all just operations performed on, or decisions made about, the identity.