What Is Application Onboarding in SailPoint IIQ?
Application onboarding in SailPoint IdentityIQ (IIQ) is the process of bringing a new system into governance scope — configuring a connector, defining the account schema, mapping identities, and aggregating accounts and entitlements so IIQ can manage who has access. It is Module 3 of the SailPoint Academy 14-module curriculum and the most-used skill in real IIQ projects.
Put simply: before SailPoint can govern an application — Active Directory, a database, Workday, SAP, or a homegrown app — that application has to be "onboarded." Onboarding tells IIQ how to log in to the system, what an account looks like there, which accounts belong to which person, and how to push changes back. Every certification, access request, and lifecycle event downstream depends on onboarding being done correctly first.
Why this is the skill that gets you hired: Enterprises run hundreds of applications, and each one must be onboarded and maintained. A SailPoint IIQ professional who can confidently onboard an application end-to-end — and debug it when aggregation goes wrong — is doing the day-one work of nearly every IIQ consultant and developer role.
What Is the Difference Between Authoritative and Non-Authoritative Applications?
In SailPoint IIQ, an authoritative source is the trusted system of record — aggregating from it creates an Identity Cube for each person — while a non-authoritative application is correlated to existing identities using correlation logic. A typical authoritative source is an HR system like Workday; non-authoritative applications include Active Directory, databases, and most business apps.
This distinction drives the entire onboarding design, so it is worth getting crystal clear:
Authoritative Source
The trusted "who exists" system — usually HR (Workday, SuccessFactors, SAP HR). Aggregating it creates and updates Identity Cubes. An enterprise can have more than one authoritative source.
Non-Authoritative Application
The "what access exists" systems — AD, LDAP, databases, business apps. Their accounts are correlated to existing identities; they do not create new people in IIQ.
Get this wrong and the symptoms are immediate: mark a target app as authoritative by mistake and IIQ creates duplicate identities for every account. This is exactly the kind of design decision that distinguishes a trained professional from someone who only watched tutorial videos.
What Are the Connector Types in SailPoint IIQ?
SailPoint IdentityIQ uses three broad connector approaches: Direct Connect connectors that talk live to a system (LDAP, JDBC, web services), Datafile/Delimited connectors that read flat files such as CSV over SFTP, and custom connectors built in Java or BeanShell for systems with no out-of-the-box option. IIQ ships with connectors for common systems like Active Directory, SAP, and Salesforce.
| Connector Type | How It Works | Best For | Onboarding Effort |
|---|---|---|---|
| Direct Connect | Live connection via LDAP, JDBC, SCIM, or web services API | AD, databases, cloud apps with APIs | Low–Medium (out-of-box) |
| Datafile / Delimited | Reads CSV/flat files from local, FTP, FTPS, SCP or SFTP | Legacy apps, HR extracts, systems with no live API | Medium (file format dependent) |
| Custom Connector | Java/BeanShell code defining aggregation & provisioning | Homegrown or unsupported applications | High (developer skill) |
A useful mental model: an application in IIQ is a configured instance of a connector. The connector is the engine; the application is the engine wired up with one specific system's hostname, credentials, and schema. Choosing the right connector type is the first real decision of any onboarding.
What Are the Steps to Onboard an Application in SailPoint IIQ?
Onboarding an application in SailPoint IIQ follows six core steps: define the application scope and source type, select and configure the connector, define the account schema, configure identity mapping and correlation, run account aggregation, and then test provisioning before going to production. The same sequence applies whether the system is Active Directory or a custom app.
Define scope and source type
Identify the application, its business owner, and whether it is authoritative (creates identities) or non-authoritative (correlates to existing ones). This single decision shapes the rest of the build.
Select and configure the connector
Pick Direct Connect, Datafile, or a custom connector, then enter connection parameters — host, port, service account credentials, file path, or API endpoint.
Define the account schema
Tell IIQ what an account looks like: which attributes are the account ID, display name, email, employee ID, and which attributes hold entitlements and group memberships.
Configure identity mapping and correlation
Map application attributes to identity attributes (for example account "mail" to identity "email") and set correlation logic so accounts link to the right Identity Cube instead of creating duplicates or orphans.
Run account aggregation
Execute an aggregation task to pull accounts and entitlements into IIQ. Authoritative aggregation builds identity cubes; non-authoritative aggregation correlates accounts to existing people.
Test provisioning, then promote to production
Validate that access requests, provisioning, and deprovisioning behave correctly, then deploy to production and govern the app through access certifications and lifecycle events.
Want to onboard a real application live, with a trainer?
Attend a free 60-minute live demo before you decide. No payment, no commitment — watch an actual IIQ onboarding walkthrough.
How Do Schema and Identity Mapping Work in IIQ?
In SailPoint IIQ, the account schema defines the structure of an application's accounts — which attributes exist and which one is the identity attribute — while identity mapping connects those account attributes to attributes on the IdentityIQ Identity Cube. Correlation logic then uses these mappings to attach each aggregated account to the correct person.
Three terms trip up most beginners, so here is the plain version:
- Schema — the blueprint of an account in the target system: account ID, name, email, department, and the multi-valued attributes that represent entitlements or groups.
- Identity mapping — rules that say "this application attribute populates this identity attribute," so IIQ can build a unified profile of a person across many systems.
- Correlation — the matching logic (for example, match account employeeId to identity employeeNumber) that decides which Identity Cube an account belongs to. Weak correlation is the number-one cause of orphan accounts.
These concepts connect directly to later modules — once accounts are correctly correlated, IIQ can run access certifications and lifecycle events against real, deduplicated identities.
What Is the Difference Between Aggregation and Provisioning?
In SailPoint IIQ, aggregation reads data — it pulls accounts and entitlements from an application into IdentityIQ — while provisioning writes data, pushing changes such as new accounts, access grants, or removals from IIQ back to the target system. Onboarding configures both directions so an application is fully governed, not just observed.
| Aspect | Aggregation (Read) | Provisioning (Write) |
|---|---|---|
| Direction | Application → IIQ | IIQ → Application |
| Purpose | Discover accounts & entitlements | Create, modify, or remove access |
| Triggered by | Scheduled aggregation tasks | Access requests, lifecycle events, role changes |
| Optional custom logic | Aggregation rule (BeanShell) | Provisioning / connector rule (BeanShell) |
A system can be onboarded as read-only (aggregation only) — common for early governance and certifications — and later upgraded to full provisioning once the organisation trusts IIQ to make changes automatically. Knowing when to do which is practical judgement that comes from working real scenarios, which is the core of how SailPoint Academy's live IIQ course is taught.
What Are the Most Common Onboarding Mistakes?
The most common SailPoint IIQ onboarding mistakes are wrong authoritative-source designation, weak correlation logic that creates orphan accounts, an incomplete account schema, and skipping provisioning testing before production. Orphan accounts — accounts that fail to correlate to any identity — are the single most frequent real-world onboarding problem.
Orphan accounts after aggregation
Accounts that don't match any identity. Usually caused by correlation keys (like employee ID) being blank or formatted differently across systems.
Wrong authoritative flag
Marking a target app authoritative creates duplicate identities. Only true systems of record (usually HR) should be authoritative.
Incomplete schema
Missing entitlement attributes means certifications and access requests can't see real access. Confirm the schema captures groups and entitlements.
No provisioning test
Going live without testing deprovisioning is how leavers keep access. Always validate the write path in a non-production environment first.
What Do Interviewers Ask About Application Onboarding?
Application onboarding is one of the most frequently tested SailPoint IIQ interview topics, with interviewers commonly asking about authoritative vs non-authoritative sources, connector types, account schema, correlation rules, and how to troubleshoot orphan accounts after aggregation. These questions appear in technical rounds at GCCs, Big 4 consulting, and IT services firms.
Questions practitioners report being asked, drawn from public SailPoint interview question collections:
- What is the difference between an authoritative and a non-authoritative source, and what happens if you misconfigure it?
- Walk me through onboarding a new application end-to-end.
- What is a correlation rule, and when would you write one instead of using attribute-based correlation?
- How do you debug orphan accounts after an aggregation run?
- When would you use a Datafile connector instead of Direct Connect?
- What is the difference between aggregation and provisioning?
If you can answer these confidently with examples, you are interview-ready on this module. For a broader set, see our SailPoint IIQ interview questions guide, and review where this module fits in the full 14-module IIQ curriculum.
Frequently Asked Questions
These are the questions IT professionals most often ask about SailPoint IdentityIQ (IIQ) application onboarding — drawn from practitioner forums, interview-question collections, and the questions students raise during SailPoint Academy live sessions. Each answer maps to Module 3 of the 14-module IIQ curriculum.
Onboard Real Applications, Not Just Slides
Attend a free 60-minute live demo — watch a real IIQ application onboarding, ask the trainer anything, and decide with complete clarity. No payment. No commitment.