SailPoint IIQ Architecture Explained 2026

Quick Answer: SailPoint IIQ architecture is a Java web application tier, a relational database that holds the identity warehouse and configuration, a set of connectors that talk to target systems, and IQService for Windows operations. High availability is not just two application servers behind a load balancer; it is a shared database, consistent configuration, healthy IQService pools and tasks that do not collide.

SailPoint IIQ Architecture at a Glance

Most architecture diagrams stop at “server, database, connector” and then skip the parts that cause production incidents. The useful view separates responsibilities and failure modes. If you can point to the component that failed when a provisioning request hangs, you understand the architecture.

The Four Tiers You Need to Separate

Presentation tier. The browser and the reverse proxy sit here. Users reach the admin console and Lifecycle Manager. This tier should not be where you debug a connector timeout, but it is where users first notice one.

Application tier. One or more IIQ nodes run the Java application. They share configuration through the database, but they do not share JVM memory. A rule that caches data in a static variable behaves differently across nodes; do not assume one node’s memory is the cluster’s memory.

Data tier. The database is the source of truth for IIQ objects. It holds identities, links, applications, roles, policies, certifications, tasks and audit records. Performance problems here look like application problems: slow pages, timed-out tasks and a console that feels “stuck”.

Integration tier. Connectors and IQService talk to the outside world. This is where network latency, target-system permissions and schema mismatches live. A healthy IIQ application can still fail every provisioning request because IQService is down.

How a Request Becomes a Provisioning Action

A user requests a role in Lifecycle Manager. IIQ checks the request, evaluates policy, routes it for approval, and then builds a provisioning plan. The plan is a structured description of account changes. The provisioner executes it through the connector, and the target system confirms the result.

1. Request: the user or manager selects a role or entitlement.
2. Policy evaluation: IIQ checks SoD, assignment rules and approvals.
3. Plan: IIQ translates the request into account and entitlement changes.
4. Provision: the connector or IQService performs the change.
5. Reconcile: IIQ confirms the target state and updates the link.

When someone says “IIQ is slow”, ask which step. A slow approval is a workflow or notification problem. A slow plan is often a role model or policy problem. A slow provision is usually the target system, connector or IQService.

Where the Identity Warehouse Lives

The identity warehouse is not a separate product; it is the set of IIQ tables in the relational database. It stores the current identity view and the history needed for audit. That has two consequences. First, database sizing and indexing matter. Second, you cannot treat the warehouse as a disposable cache; a bad refresh can change access state.

Keep the database close to the application tier. A 5 ms query is fine; a 50 ms query repeated thousands of times during a refresh is not. Work with the DBA on connection pooling, table statistics and archive strategy before a large aggregation, not after.

# Simplified iiq.properties connection shape (values vary by deployment)
iiq.datasource.url=jdbc:sqlserver://db-host:1433;databaseName=identityiq
iiq.datasource.username=iiq_app
iiq.datasource.password=use-a-secret-manager
iiq.datasource.maxActive=50
iiq.datasource.maxIdle=10
iiq.datasource.validationQuery=SELECT 1

Do not copy these numbers into production. Pool size depends on node count, database limits and task concurrency. Too many connections can hurt more than too few.

IQService and the Windows Boundary

IQService is a Windows service that performs AD operations on behalf of IIQ. It is often installed on a separate host, sometimes near the domain controller. The IIQ application talks to IQService over a configured port; IQService uses Windows APIs and the service account permissions to create accounts, change groups and reset passwords.

Three details matter. First, IQService has its own logs; an IIQ provisioning error may only show a generic failure. Second, the service account needs the right OU permissions, not domain admin. Third, IQService pools should be sized and monitored like any other integration component. If the service is down, IIQ will not fail over to a different Windows protocol just because the page looks healthy.

Security Boundaries and the Identity Perimeter

IdentityIQ sits on a dangerous boundary: it can read every identity in the company and write access to critical systems. Treat it as a tier-zero application. That means network segmentation, TLS everywhere, a dedicated service account, restricted administrator access and audit logging that is separate from the application team’s control.

Four controls deserve explicit design. First, the IIQ database should not accept connections from arbitrary hosts; allow only the application nodes and approved administration tools. Second, connector credentials should come from a secrets manager or an encrypted credential store, not a shared spreadsheet. Third, administrative roles should be separated from day-to-day service accounts, and every privileged action should be attributable to a person. Fourth, outbound connections from IIQ to target systems should be allow-listed by destination and port.

The most overlooked boundary is the rule sandbox. BeanShell rules execute inside the application with significant privileges. A rule that reads an arbitrary file, calls an unapproved endpoint or logs personal data can create a security incident that no connector permission will stop. Review rules like production code, and keep a short list of people who can promote them.

High Availability and Load Balancing

A common mistake is to put two IIQ nodes behind a load balancer and call it highly available. That gives you application-tier redundancy, but it does not solve database failover, IQService redundancy, task collision or configuration drift. A real HA design covers all of them.

• Use a shared database with a supported failover mechanism, not a local database per node.
• Keep IIQ versions and configuration identical across nodes.
• Use sticky sessions if your deployment requires them; test failover, not just login.
• Run scheduled tasks on one node or use a task scheduler that prevents duplicate execution.
• Provide redundant IQService endpoints where AD provisioning is business-critical.
• Monitor JVM heap, thread pools, database connections and task queues per node.

Test a node failure during an aggregation and during a provisioning request. If the task continues on the other node but the user session is lost, that may be acceptable; if two nodes run the same aggregation, it is not.

Performance Bottlenecks That Actually Hurt

Aggregation queries. The connector may pull more data than the business needs. Filter at the source, page the results, and check the query plan. A full table scan on a large HR system will hurt every run.

Correlation rules. A rule that calls an external service for every account turns an aggregation into a network test. Cache reference data or move the lookup to a scheduled enrichment step.

Refresh scope. A full refresh of every identity after a small application change is wasteful. Use targeted refresh where the dependency graph allows it, and know which changes trigger provisioning.

Database contention. Certification generation, reporting and large refreshes can compete for the same tables. Stagger them. A report that runs at 9 a.m. on the first of the month is a self-inflicted incident.

JVM and threads. More heap is not a fix for a leak or a bad query. Watch garbage collection, thread dumps and connection pools. If the application is spending its time waiting on the database, adding memory just delays the failure.

Deployment Sizing Checklist

What Breaks in Production

A bank I worked with had two IIQ nodes and a shared database. Everything looked highly available until month-end certification generation. Both nodes picked up the task, the database connection pool saturated, and the Lifecycle Manager started timing out. The application tier was fine; the scheduling design was not.

The fix was not more heap. They pinned certification generation to a dedicated task node, staggered the reporting jobs, and added a database connection budget per node. The lesson: HA is a system property, not a server count.

Training Resources

If you want to see these components in a working lab, SkilBrill’s SailPoint IdentityIQ training covers deployment concepts, application onboarding, task tuning and troubleshooting. For the wider IAM picture, the IAM training track is a useful companion.

Read next: SailPoint IIQ tutorial, IIQ developer roles, and IIQ interview questions.

FAQ

Does SailPoint IIQ require a separate database?

Yes. IdentityIQ uses a supported relational database for its identity warehouse and configuration. The database is part of the IIQ deployment, not an optional add-on.

What is IQService used for?

IQService performs Windows operations, most commonly Active Directory account and group changes, on behalf of IdentityIQ. It runs as a separate Windows service and has its own logs and permissions.

Can IdentityIQ run in containers?

The application can run in supported containerised deployments, but the database, IQService and target-system integrations still need a production-grade design. Containerisation does not remove state or Windows dependencies.

How many IIQ nodes do I need for high availability?

At least two application nodes are common, but the right number depends on user load, task concurrency, database limits and your recovery objectives. Two nodes without database and scheduler redundancy is not a complete HA design.

What causes slow aggregation in IdentityIQ?

The usual causes are an expensive source query, missing indexes, too much data, a rule that calls an external service per account, or running the task during a peak window. Check the connector and source system before adding JVM memory.

Written by SkilBrill Training Institute

October 25, 2026 · 9 min read