Most engineers think…
Most people describe SailPoint as 'an RBAC tool that runs access reviews'. That answer is too narrow for an interview and too shallow for a real deployment.
SailPoint IdentityIQ is a full identity governance platform: a central identity warehouse where every managed user gets an Identity Cube — a multi-dimensional record of every account, entitlement, role, risk score and policy violation across all connected applications. The connector layer aggregates that data from authoritative sources; the Lifecycle Manager provisions and deprovisions it; and the Compliance Manager certifies it. Understanding that architecture — and when to stay on IIQ versus move to Identity Security Cloud — is what separates a junior implementer from a senior one.
① What SailPoint IdentityIQ is — the identity warehouse and Identity Cubes
The single most important idea in IIQ: every managed user is represented by an Identity Cube. The Cube is not just an LDAP record — it is a consolidated view of everything IIQ knows about that person: which accounts they hold on which systems, which entitlements and roles they carry, their composite risk score, any open policy violations and the full history of access changes.
All Identity Cubes live in the identity warehouse — IIQ's central database (typically MySQL, Oracle or SQL Server). The warehouse is the source of truth for provisioning decisions, policy checks and certification campaigns. Data flows in from authoritative sources (HR systems like Workday or SAP HCM) and managed applications (Active Directory, SAP ERP, Salesforce, etc.) via the connector layer, and the warehouse is refreshed on a schedule or on-demand.
IIQ ships as a Java web application (WAR) deployed on an application server such as Apache Tomcat, backed by a relational database and optionally clustered for HA. The entire platform — governance policies, workflows, certifications, provisioning plans — is driven from this single codebase, customised via BeanShell scripts and XML rules.
When asked 'how does IIQ work?', lead with the identity warehouse and Identity Cubes — not with certifications or the UI. The warehouse is the architectural foundation everything else depends on. Aggregation feeds it; Lifecycle Manager reads it to build provisioning plans; Compliance Manager queries it to drive certification campaigns.
What is an Identity Cube in SailPoint IdentityIQ?
② Application onboarding — connectors, aggregation and authoritative sources
Application onboarding is the process of connecting a source system so IIQ can read accounts and entitlements, and optionally write provisioning changes back. IIQ supports three connector models. Direct connectors (built-in) cover the most common targets: Active Directory, LDAP, JDBC databases, flat files, SAP, and many major SaaS platforms. Virtual Appliance (VA) connectors run as a lightweight on-prem agent so IIQ's cloud or DMZ-hosted engine can reach internal systems without opening inbound firewall ports. Custom / REST connectors use the Connector SDK or the REST Integration Framework for anything else.
Aggregation and authoritative sources
Once an application is onboarded, aggregation pulls all accounts and entitlements into the identity warehouse and links them to Identity Cubes. A designated authoritative source (commonly an HR feed) is the master for identity attributes like name, department and manager — when a record changes there, IIQ detects the change and triggers provisioning via a Joiner, Mover or Leaver event. Non-authoritative sources are managed applications: IIQ reads their accounts but defers to the authoritative source for identity truth.
The central SQL database that stores all Identity Cubes — each user's full picture of accounts, entitlements, roles, risk scores and policy violations across every connected application.
A multi-dimensional record for one managed user: accounts, entitlements, roles, risk score, policy violations and access history — the unit IIQ governs against.
Direct, Virtual Appliance and REST connectors that pull account/entitlement data in from applications and push provisioning changes out. One framework for all targets.
The provisioning engine for Joiner, Mover and Leaver events — drives approval workflows, builds provisioning plans, and submits them to connectors or manual work queues.
Only HR (or a master IdM) should be flagged as the authoritative source for identity attributes like name, department and manager. If you mark Active Directory as authoritative, IIQ will trust AD over HR — and when someone's department changes in Workday, IIQ will see a conflict, defer to AD, and the Mover workflow will never fire. One authoritative source per attribute, period.
Your company's IIQ servers sit in a DMZ but the HR system is on a private LAN with no inbound internet access. Which connector approach works?
③ Lifecycle Manager and Compliance Manager — provisioning and certifications
IIQ's two flagship modules handle the two halves of identity governance. Lifecycle Manager is the provisioning engine for Joiners (new hires), Movers (role changes) and Leavers (terminations). It drives approval workflows, generates provisioning plans (a structured list of account create / modify / delete operations), and submits them to target applications via the connector layer. Plans are executed directly (if the connector supports write-back) or queued as manual work items if the target is unmanaged.
Compliance Manager handles the other half: periodic and triggered access certifications (also called access reviews), Segregation of Duties (SoD) policy enforcement, and audit reporting. Certifiers (managers or application owners) see a campaign workqueue in the IIQ UI and make Approve / Revoke / Delegate decisions; revocations feed directly back into Lifecycle Manager for automated removal.
Together, the two modules enforce the principle of least privilege continuously: Lifecycle Manager grants only the right access at the right time, and Compliance Manager removes excess access that has drifted in.
Priya at a Mumbai NBFC faces this
Newly onboarded employees are getting accounts created but with no entitlements, so they cannot log in to any application on day one.
The Joiner workflow provisioning plan is being generated correctly but the birthright role assignments are not triggering because the HR feed is not flagged as the authoritative source for the 'department' attribute.
Open IIQ ▸ Application Definition ▸ HR Feed ▸ Schema — 'department' attribute is not marked as authoritative. Role selector rules match on department, so no department = no roles assigned.
Application ▸ Schema ▸ authoritative attribute flagsMark 'department' (and 'jobCode', 'location') as authoritative in the HR application schema. Re-run aggregation. The role assignment rule will now fire correctly and birthright roles will populate the provisioning plan for all new hires.
Create a test hire record in the HR feed, trigger aggregation, confirm the Identity Cube shows the correct department and that the Joiner workflow generates a provisioning plan with the expected birthright roles and AD group memberships.
▶ Watch a Joiner event provision a new hire end-to-end
How a new hire record in Workday becomes an active AD account. Press Play for the healthy path, then Break it to see the classic authoritative-source failure.
A user's manager has just approved an access request in IIQ. What happens next?
④ Deploying IIQ — sizing, clustering, and when to choose ISC instead
A production IIQ deployment has at least two application server nodes behind a load balancer for HA, a clustered database (MySQL or Oracle RAC are common), and a shared file store for documents and log exports. The IIQ application server nodes are stateless (session state in the database), so horizontal scaling is straightforward. Virtual Appliance nodes live inside the corporate network for direct connector reach; the IIQ servers can sit in a DMZ or private cloud.
IIQ vs Identity Security Cloud (ISC)
IIQ is the right choice when: the organisation needs deep BeanShell / Java customisation, has on-prem authoritative sources (HR mainframes, legacy LDAP), or has strict data-residency requirements that prohibit a multi-tenant SaaS. ISC (SailPoint's SaaS platform, built on the Atlas architecture) is the right choice when: the organisation prefers a fully managed, auto-upgraded platform, can express governance logic in declarative configuration rather than custom code, and is willing to trade customisation depth for lower operational overhead. SailPoint itself actively encourages migration from IIQ to ISC, noting typical TCO reductions of 10–30%. Ten to thirty percent of heavily customised IIQ logic may need redesign in ISC because some BeanShell extension points do not exist in the SaaS model.
Ask two questions before the architecture decision: (1) Does the org have custom BeanShell rules or Java connectors that would not port cleanly? (2) Does a regulator require data to stay inside a specific geography? A 'yes' to either is a strong signal to stay on IIQ. If the answer is 'we mostly use SaaS apps and want auto-upgrades', ISC is the better choice — and SailPoint's own migration path is well-documented.
An organisation runs a mainframe-based HR system with strict EU data-residency rules. Which SailPoint platform is the better fit?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: what is the identity warehouse and why is it the architectural centre of SailPoint IdentityIQ? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Identity Warehouse
- The central SQL database in IIQ that stores all Identity Cubes — the single source of truth for provisioning decisions, policy checks and certification campaigns.
- Identity Cube
- A multi-dimensional record for one managed user, aggregating all accounts, entitlements, roles, risk score and policy violations from every connected application.
- Authoritative Source
- The application (usually HR) whose identity attributes IIQ trusts as the master record — name, department, manager and jobCode all flow from here to drive role assignments and JML events.
- Lifecycle Manager
- The IIQ module that handles Joiner, Mover and Leaver events — builds approval workflows and provisioning plans, and submits them to connectors for execution.
- Compliance Manager
- The IIQ module that runs access certification campaigns, enforces SoD policies, and generates audit reports; revocations feed back automatically to Lifecycle Manager.
- Virtual Appliance (VA)
- A lightweight on-premises agent that relays aggregation and provisioning traffic between IIQ servers (which may be in a DMZ or cloud) and internal target systems, with no inbound firewall exposure.
- Provisioning Plan
- A structured list of account operations (create, modify, delete, enable/disable) that Lifecycle Manager builds from approved requests and submits to the appropriate connectors.
- Segregation of Duties (SoD)
- A policy in Compliance Manager that flags or blocks combinations of entitlements a single user should not hold simultaneously — e.g. the ability to create a supplier and approve payments to them.
- Identity Security Cloud (ISC)
- SailPoint's SaaS identity governance platform built on the Atlas architecture — shares the IIQ identity model and connector framework but uses declarative configuration instead of BeanShell.
- Aggregation
- The IIQ process of reading all accounts and entitlements from a connected application and linking them to Identity Cubes in the warehouse — the first step in governing any application.
📚 Sources
- SailPoint — IdentityIQ product page and documentation. documentation.sailpoint.com/identityiq
- SailPoint — Identity Warehouse: Identity Cubes, attributes and risk scores in IdentityIQ. documentation.sailpoint.com/identityiq/help/identity_management/identity_warehouse.html
- SailPoint — Why you should migrate from IdentityIQ to SailPoint Identity Security Cloud. sailpoint.com/blog/why-you-should-migrate-from-identityiq-to-sailpoints-identity-security-cloud
- Identity Logic Consulting — SailPoint IdentityIQ vs Identity Security Cloud vs Saviynt EIC: A Practitioner's Comparison. identitylogicconsulting.com
- EnH iSecure — SailPoint IdentityIQ Production Architectures (2025). enhisecure.com/isecureblog/2025/03/25/sailpoint-identityiq-prod-architectures/
- Heptarc — Architecture of SailPoint IdentityIQ: components, connectors and deployment. heptarc.com/architecture-of-sailpoint-identityiq/
What's next?
Got the architecture? Next, go deep on SailPoint access certifications — how the review campaign works, what certifiers see, how decisions flow back to provisioning, and how to cut your remediation time in half.