Ask ten SailPoint candidates what provisioning is and nine will say "it creates user accounts automatically". That answer is not wrong, but it describes the outcome, not the mechanism — and interviewers for SailPoint IdentityIQ roles almost always ask the follow-up: what happens between the approval and the account? The candidates who can narrate that sequence get shortlisted. The rest get thanked for their time.
Quick answer: Provisioning in SailPoint IdentityIQ (IIQ) is the outbound process of creating, modifying, enabling, disabling or removing accounts and entitlements on connected target systems. IdentityIQ records the intended change as a master provisioning plan, the Provisioning Broker compiles that plan — expanding roles, applying provisioning policies, asking for missing data, checking dependencies — and then partitions it into one plan per target system. Each partitioned plan is executed by a connector, an integration executor, or a manual work item. The plan is the unit of work; the connector is only the last mile.
This guide covers the full pipeline in the order IdentityIQ actually runs it, with the vocabulary interviewers use. It is written from the same material we teach in our live online SailPoint IIQ course, where provisioning is not a slide but something you configure and watch fail on a real system.
What is provisioning in SailPoint IIQ?
Provisioning in SailPoint IdentityIQ (IIQ) is the outbound process of creating, modifying, enabling, disabling or deleting accounts and entitlements on connected target systems, driven by an approved request or an automated governance decision. Where aggregation reads account data into IdentityIQ, provisioning pushes an authorised change back out through the same connector.
The word that matters in that definition is governed. Any scripting language can create an Active Directory account. What SailPoint IdentityIQ adds is the paper trail around it: who asked, who approved, which policy permitted it, what exactly was changed, when, and whether the target system confirmed it. An auditor at an Indian bank does not ask whether the account creation was automated. They ask who approved it and on what date — and provisioning is the process that can answer.
The distinction that separates governance from scripting: a provisioning action that succeeds but leaves no record is not governance. This is why SailPoint IdentityIQ writes an identity request for every provisioning activity, even when the change is performed manually by a human being on a disconnected system.
Aggregation and provisioning are opposite directions on the same road, and they share the connector layer. Our guide to SailPoint IIQ connectors covers that layer in detail; if you are still mapping the inbound direction, application onboarding explained is the companion read.
What triggers provisioning in SailPoint IIQ?
SailPoint IdentityIQ provisioning is triggered by six main request sources: a self-service access request, a role assignment, a lifecycle event, a revocation decision in a certification campaign, a password management action, and a direct administrative change to an identity. All six converge on the same provisioning engine.
This convergence is the design insight most training material misses. IdentityIQ does not have one provisioning path for joiners and another for access requests. It has one engine, fed by several doors. Understanding that is what lets an engineer debug a failed leaver event using the same technique they would use on a failed access request.
| Request source | Typical trigger | Direction |
|---|---|---|
| Access request | A user requests an application or entitlement from the request catalogue | Grant |
| Role assignment | An identity matches role criteria, or a role is assigned by an administrator | Grant |
| Lifecycle event | HR data changes — joiner, mover, leaver or rehire | Grant or revoke |
| Certification revocation | A reviewer revokes access during an access certification campaign | Revoke |
| Password management | A self-service password reset or a forced expiry | Modify |
| Administrative change | An IdentityIQ administrator edits an identity directly | Grant, modify or revoke |
Request sources summarised from SailPoint's official IdentityIQ provisioning documentation (documentation.sailpoint.com), reviewed September 2026.
Provisioning and deprovisioning use the same engine and the same plan structure; only the operation inside the plan differs. A grant carries Create, Enable, Add or Set operations. A revoke carries Disable, Remove or Delete. In practice deprovisioning is the higher-stakes direction — a delayed grant annoys an employee, while a leaver whose accounts stay live is an audit finding with a date attached. The joiner-mover-leaver triggers are covered end to end in our SailPoint IIQ lifecycle events guide.
What is a provisioning plan in SailPoint IdentityIQ?
A provisioning plan in SailPoint IdentityIQ is the object describing the access change IdentityIQ intends to make — which identity, which application, which account, and which attributes or entitlements to add, set or remove. IdentityIQ builds a master provisioning plan for the whole request, then compiles it into smaller partitioned plans, one per target system.
Think of the master plan as the intent and the partitioned plans as the dispatch notes. A single request to onboard a new analyst in a Hyderabad GCC might produce one master plan and four partitioned plans — Active Directory, the core banking application, a ticketing tool and a shared mailbox — each handed to a different connector with different credentials and different failure modes.
Master provisioning plan
The complete intended change for one request, before compilation. It may still contain abstract items such as role names rather than concrete entitlements.
Partitioned plan
One plan per target system, produced at the end of compilation. Each is routed to the connector or integration configured for that specific target.
Unmanaged plan
Whatever no connector or integration can execute. SailPoint IdentityIQ routes it to a human through a work item instead of silently dropping it.
In a custom workflow, the provisioning plan travels as a workflow variable, which is exactly why workflow and provisioning skills are tested together. Our custom workflows explainer follows that variable through an approval chain step by step.
What is a provisioning policy in SailPoint IIQ?
A provisioning policy in SailPoint IdentityIQ is a form attached to an application or role that defines which attributes a provisioning request must supply, and how each value is obtained. Values can be typed by a person, set to a static default, or calculated by IdentityIQ using a script or rule.
Provisioning policies exist because target systems are fussy. Active Directory will not create an account without a sAMAccountName; an HR-adjacent application may demand a cost centre code that appears nowhere in the access request. The provisioning policy is where an implementer declares those requirements once, so that every future request for that application collects the right data automatically.
Where a value cannot be derived, IdentityIQ records it as a question on the provisioning project and presents it to a person on a form — typically through the Do Provisioning Forms business process. Field owners can be assigned so that a question about a cost centre goes to a finance approver rather than to the requester, which is the sort of detail that distinguishes a configured system from a working one.
A common learner mistake: assuming a provisioning policy grants access. It does not. A provisioning policy only supplies the attribute values an account needs to be created correctly. What access the person gets is decided by roles, entitlement requests and policy — the subject of our role management and RBAC guide.
How does the SailPoint IIQ provisioning engine process a request?
SailPoint IdentityIQ processes a provisioning request in five compilation stages before any target system is touched: build the master plan, expand roles into entitlements, apply provisioning policies and identify questions, filter and check dependencies, then partition the plan by target. The component that performs this is the Provisioning Broker, using the Plan Compiler.
Being able to narrate these five stages in order is, in our experience running mock interviews, the single highest-return thing a SailPoint candidate can memorise — not because interviewers want recitation, but because the sequence explains every provisioning bug they will ever be asked to debug.
Build the master provisioning plan
The request source hands IdentityIQ an intent. IdentityIQ records it as a master provisioning plan and opens a workflow case to track the activity through to completion.
Debug clue: if no plan exists, the problem is upstream — the trigger never fired.Expand roles into raw entitlements
If the plan assigns a role, the Plan Compiler expands it into the actual entitlements that role contains. After expansion, the IT role name no longer appears in the project — only the concrete account changes it implies.
Debug clue: over-provisioning usually traces back to role definition, not to the connector.Apply provisioning policies and identify questions
Provisioning policy forms fill in required attributes. Anything that cannot be calculated becomes a question recorded on the project and presented to a person on a form.
Debug clue: a request "stuck" for days is often an unanswered question sitting in someone's inbox.Filter and check dependencies
IdentityIQ removes redundant requests and uses dependency settings to order the work — an account must exist before entitlements can be added to it. If a dependency plan fails, the plans that depend on it fail with it; if it needs a retry, the dependent plans wait for the retry to succeed.
Debug clue: a cluster of failures with one root cause is almost always a dependency chain.Partition the plan and execute it
The compiled project is split into one partitioned plan per target, identified by the connector or integration configuration for that system. Anything unroutable lands in the unmanaged plan for manual handling.
Debug clue: check which partition failed before blaming the request.Compilation stages as documented in SailPoint's official IdentityIQ provisioning documentation — "Processing Provisioning Requests" (documentation.sailpoint.com), reviewed September 2026.
Execution then happens one of four ways: a read/write connector writing directly to the target, an integration executor handing the request to another provisioning or ITSM system, an internal IdentityIQ update for things like role assignments, or a work item for a human. The difference between them is not cosmetic — it decides whether IdentityIQ can report the change as committed or only as queued.
Reading about plan compilation is not the same as watching one fail
Attend a free 60-minute live demo before you decide — no payment, no commitment. Ask the trainer to walk a provisioning request from access catalogue to failed partition, and judge the teaching on that.
What happens when an application cannot be provisioned automatically?
When no connector or integration can execute part of a SailPoint IdentityIQ provisioning plan, those requests are placed in the unmanaged plan and turned into manual work items. Each work item carries the provisioning instructions and is assigned to a person — usually the application or entitlement owner — who performs the change and marks it complete.
This matters more than its coverage in most courses suggests, because no enterprise connects everything. Legacy mainframe applications, small vendor tools and internally built systems in Indian BFSI environments routinely stay disconnected for years, and governance still has to cover them.
There is a subtlety here that interviewers love. Provisioning performed through a work item is recorded as queued, not committed, even after the assignee marks it complete — because IdentityIQ has no way to verify the change until the next aggregation from that application brings the account data back in. Integration executors are treated the same way, since they cannot report completion in real time. Only direct read/write connectors and internal IdentityIQ updates can report a committed status immediately.
Read/write connector — committed
The connector writes to the target and reports back in real time. IdentityIQ marks the item committed.
Integration executor — queued
The request is handed to another provisioning or ITSM platform, which cannot report completion back to IdentityIQ, so it stays queued.
Internal IdentityIQ update — committed
Changes such as role assignments or identity attributes need no connector and are committed immediately.
Manual work item — queued until aggregated
A person performs the change and closes the work item; the next aggregation is what actually confirms it happened.
Why does provisioning fail in SailPoint IIQ?
Most SailPoint IdentityIQ provisioning failures are environmental rather than logical — connectivity and certificate errors, missing mandatory attributes, target-side constraints, and dependency failures account for the large majority. Threads on the SailPoint Developer Community reviewed in September 2026 show the same handful of causes recurring for years.
Representative examples from that community: an Active Directory joiner failing with an IQService InvalidConfigurationException; intermittent provisioning failures traced to a TLS trust problem reported as "PKIX path building failed: unable to find valid certification path to requested target"; and accounts that are visibly created in the target while IdentityIQ still records the request as failed. That last pattern is worth internalising — a provisioning request marked failed in SailPoint IdentityIQ does not always mean nothing happened on the target system, which is why remediation always starts by comparing the identity request against the target's own state.
| Failure pattern | Usual root cause | Where to look first |
|---|---|---|
| Connectivity / certificate errors | Service account, firewall or TLS trust chain to the target | Connector test connection, then application logs |
| Missing mandatory attribute | Provisioning policy does not supply a field the target requires | The provisioning policy form and any unanswered questions |
| Target-side rejection | Duplicate account name, invalid OU, password complexity rules | The target system's own error text on the identity request |
| Cascade of failures | A dependency plan failed, so dependent plans failed too | Dependency ordering on the compiled project |
| Stuck, not failed | An unanswered provisioning question or a pending work item | Open work items for the requester and field owners |
Failure patterns summarised from public SailPoint Developer Community IIQ discussion threads and SailPoint's provisioning documentation, reviewed September 2026.
Where a failure needs custom handling — notifying an application owner, retrying with altered data, transforming a plan before it reaches a connector — the work is done in a provisioning rule. Our SailPoint IIQ rules and BeanShell guide covers the rule types and where each one fires.
How is provisioning different in SailPoint ISC?
Provisioning in SailPoint Identity Security Cloud (ISC) follows the same governance concepts as SailPoint IdentityIQ but is configuration-driven rather than code-driven. IdentityIQ exposes an engineer-facing workflow and rule engine with deep Java and BeanShell customisation; ISC favours transforms, identity profiles and lifecycle states that most teams can configure without scripting.
For a learner in 2026 the practical consequence is that IIQ provisioning knowledge transfers to ISC conceptually but not syntactically. The plan-then-execute mental model survives the move; the BeanShell rule does not. Complex on-premise provisioning — mainframe RACF and ACF2, older ERP platforms, heavily customised approval chains — still tends to sit on IdentityIQ, which is a large part of why both platforms continue to be advertised side by side in Indian job descriptions.
The cloud equivalent of an IIQ rule is examined in our SailPoint ISC transforms explainer, and the platform decision itself in SailPoint IIQ vs IdentityNow. SailPoint Academy is also launching a live online SailPoint ISC (Identity Security Cloud) course — the waitlist is open.
What do interviewers ask about SailPoint provisioning?
Provisioning interview questions almost always move from definition to mechanism within two follow-ups. Interviewers open with "what is provisioning", then test whether the candidate can describe a provisioning plan, explain manual versus automated provisioning, and debug a request that failed — the questions a person who has only watched tutorials cannot answer.
The questions we see most often in mock interviews with working professionals in Hyderabad, Bangalore and Pune:
"Walk me through what happens after an access request is approved."
They are listening for plan, compilation, partitioning and execution — in that order, with the words used correctly.
"What is the difference between a provisioning plan and a provisioning policy?"
The plan is the change to be made; the policy is the form that supplies the attribute values the change requires.
"How would you provision to an application with no connector?"
Unmanaged plan, manual work item to the application owner, and confirmation only at the next aggregation.
"A provisioning request shows failed but the account exists. What now?"
A real scenario. Compare the identity request against the target's state, find where the partition failed, and remediate without creating a duplicate.
Scenario questions of this shape are collected in our SailPoint IIQ scenario-based interview questions, and the broader question bank in SailPoint IIQ interview questions.
Where does provisioning sit in a structured IIQ course?
Provisioning is not a single module in SailPoint Academy's 14-module SailPoint IdentityIQ curriculum, because provisioning is what several modules produce together. Application Onboarding builds the connector that carries the change, Application Rules covers provisioning rules, Role Management defines what gets expanded into a plan, Lifecycle Events supplies the automatic triggers, and Custom Workflow orchestrates the approvals and forms.
That distribution is deliberate rather than untidy. A course that taught provisioning as one isolated chapter would leave a learner able to define it and unable to fix it — which is precisely the gap that shows up in interviews. The full module sequence is on our 14-module IIQ curriculum page: IAM Overview, SailPoint Architecture, Application Onboarding, SailPoint Jobs, Configuration File, Application Rules, Role Management, Policy Management, Risk Score, Groups/Workgroups/Population, Access Certification, Lifecycle Events, Custom Workflow, and Quick Link & Reporting.
Demand for these skills remains substantial in India. Naukri listed 3,918 SailPoint IdentityIQ job vacancies in India as of August 2026, alongside 6,164 vacancies mentioning SailPoint overall in September 2026. Provisioning, lifecycle events and certification campaigns appear in the majority of those job descriptions, because they are the three things an auditor actually inspects. Salary and role progression across those titles are mapped in our SailPoint IIQ salary in India 2026 guide and the IAM career roadmap.
Job counts are public Naukri listing totals for the stated search terms on the dates shown. Listing counts fluctuate daily and include duplicate and agency postings. These are market indicators, not guarantees of employment.
SailPoint Academy teaches the IIQ program 100% live online over 2 months for Rs. 25,000, with batches capped at 25 students, session recordings in the LMS, hands-on labs, and a lead trainer with 15 years of enterprise IAM experience. We provide placement assistance and career guidance, and award a SailPoint Academy certificate of completion — not an official SailPoint Technologies certification, which is available only through SailPoint's own Identity University.
Frequently Asked Questions
Watch a Provisioning Plan Compile — and Fail
SailPoint IIQ training for working professionals — Rs. 25,000, 2 months, all 14 modules, 100% live on Zoom, batch capped at 25, recordings in the LMS. Attend a free 60-minute demo first. No payment. No commitment.