SailPoint IIQ Connectors Guide 2026: Types and Onboarding

Quick Answer: SailPoint IIQ connectors are the integration components that let IdentityIQ talk to target systems — Active Directory, LDAP directories, databases via JDBC, flat files, and web services. The connector you choose decides what IIQ can discover (aggregation), how accounts are matched (correlation) and what it can change (provisioning). Choosing correctly is 60% of a clean application onboarding; the wrong choice haunts every later project phase.

What a Connector Actually Does

A connector is not just a pipe. For each application definition it handles three distinct contracts: aggregation (read accounts and entitlements from the target), provisioning (write changes — create, update, enable, disable, delete) and specialised operations (password changes, group management, sometimes via IQService on Windows targets). A connector that reads but cannot write is “discovery-only” — useful for first-phase rollouts, disappointing when the client was promised automation.

The Connector Families in Practice

Application Onboarding: The Real Sequence

Onboarding an application is the bread-and-butter IIQ project task, and interviews drill it. The sequence, simplified:

1. Inventory the target: what identifies an account, what entitlements exist, who owns the data.
2. Choose the connector and connection parameters; test connectivity before promising anything.
3. Define the schema: which attributes IIQ collects, which are entitlements, which are searchable.
4. Configure aggregation: grouping, filters, delta support.
5. Configure correlation: deterministic rules first — see the correlation rules guide.
6. Provisioning policies: how IIQ creates and changes accounts on this target.
7. Test in a sandbox with production-shaped data, including the ugly cases: nulls, duplicates, leavers.

A build-map rule customises what the connector reads before it lands in IIQ. A simple BeanShell build map that normalises employee IDs looks like this:

import sailpoint.object.ResourceObject;
import java.util.HashMap;

Map map = new HashMap();
String empId = (String) object.getAttribute("employeeId");

if (empId != null) {
    // Normalise: strip spaces and leading zeros
    empId = empId.trim();
    while (empId.startsWith("0")) {
        empId = empId.substring(1);
    }
    map.put("employeeId", empId);
} else {
    log.warn("Build map: account " + object.getName() + " has no employeeId");
}

map.put("displayName", object.getAttribute("cn"));
return map;

The null-check and the log line are not decoration — they are the difference between a rule that survives production and one that pages you at 2 a.m. (For more rule patterns, see the BeanShell rules examples.)

Choosing Between Custom and Supported Connectors

The decision rule from field experience: exhaust the supported options first. A generic JDBC or web-services connector solves more problems than clients expect. Custom connector development is a project — design, code, test, maintain across upgrades — and should need a written justification. If someone proposes a custom connector for a target that SCIM could cover, ask why twice. The exception that proves the rule: when a “custom” connector is really a supported web-services connector plus a build map, that is not customisation — it is configuration done properly.

Connector Health Monitoring

Connectors fail quietly — an aggregation that returns 90% of accounts looks “done” to a dashboard and broken to an auditor. The monitoring set that catches problems early: aggregation duration trend per application (a 20% month-over-month lengthening usually means source-side drift); record-count deltas per run (sudden drops mean feed changes, and the correlation consequences follow); provisioning queue depth, especially the IQService queue for AD, where a stalled agent shows up as “requests pending” tickets before it shows up in any graph; and error-rate per task result, trended rather than absolute, because a connector that always throws three benign errors will one day throw three hundred different ones. Wire these into whatever monitoring the client already trusts — email digests beat perfect dashboards nobody opens. The discipline costs a day to set up and routinely saves the week of cleanup that unmonitored drift eventually charges, and it is the first thing a new admin should inherit as documentation.

Estimating an Onboarding Honestly

Interviewers love asking how long an application onboarding takes, because inexperienced answers say “two days” and experienced answers ask clarifying questions first. The honest estimate decomposes: schema discovery and connectivity (predictable, hours to a day); schema mapping and correlation design (depends entirely on source data quality — this is where estimates die); provisioning policy per operation (create, enable, disable, delete, password) with field mappings and format rules; testing across the full operation set including negative cases; and documentation plus handover. A clean JDBC application with good data takes two to three days. An application with inconsistent keys, four account types and an API that rate-limits takes two weeks, and the difference is visible during discovery, not after. Quote ranges with the dependency named — “it depends on the source’s key quality, and here is the checklist that decides” — and the answer lands as seniority, not evasion.

Training Resources

Connector onboarding is a core lab track in the SailPoint IdentityIQ Certification Training — you onboard AD and database applications yourself, with IQService debugging included. The IIQ architecture guide shows where connectors sit in the platform, and the IIQ roadmap sequences connector skills in the wider curriculum. The IAM training track covers connectors beyond the SailPoint ecosystem.

FAQ

What connectors does SailPoint IIQ support?

Out of the box: Active Directory, LDAP, JDBC databases, delimited/flat files, web services (REST/SOAP), SCIM, and dozens of targeted connectors for enterprise applications. Check the current SailPoint connector documentation for the exact list per IIQ version. Treat the list as a menu of patterns rather than inventory: most production estates run on four of them, deeply configured.

What is the difference between aggregation and provisioning in connectors?

Aggregation reads: it pulls accounts and entitlements into IIQ. Provisioning writes: it creates, updates, enables or disables accounts on the target. Some connectors are discovery-only; AD via IQService does both plus password operations — the asymmetry explains why AD provisioning gets its own troubleshooting section in every runbook.

Why is IQService needed for Active Directory provisioning?

AD operations like account creation and password changes need Windows-native APIs that the Java-based IIQ server cannot make directly. IQService is the Windows-side agent that executes them. Keep its version aligned with your IIQ patch level — version drift between IIQ and IQService is the most common AD-provisioning failure in production.

Can IIQ provision to a flat file?

Not meaningfully. Flat-file connectors are for reading feeds and POC work. Write-back requires a target with an interface — a database, directory or API. Anyone selling flat-file “provisioning” is describing a CSV writer. Read-only connectors still matter — feeds drive governance decisions even when write-back lives elsewhere.

When should we write a custom connector?

Only when no supported or generic connector can perform the required operations, after web-services and JDBC options are genuinely exhausted. Custom connectors cost maintenance across every upgrade — require a written design review first, with the maintenance owner named before the code is written.

Written by SkilBrill Training Institute

October 25, 2026 · 7 min read