SailPoint provisioning
Provisioning is how IdentityIQ makes access changes happen in target systems, automatically and on request.
Provisioning is the write process. When access should change, IdentityIQ builds a provisioning plan and pushes it to the target through a connector, or hands it to a manual work item if there is no automated connector. It is triggered by lifecycle events, access requests, role assignments and certification revocations.
- Provisioning writes changes out; aggregation reads them in
- A provisioning plan describes the requested account changes
- Automated connectors execute plans; manual work items cover the rest
- Joiner, mover and leaver events drive automated provisioning
- Provisioning policies supply the required account fields
Provisioning is how IdentityIQ makes access changes happen in target systems, automatically and on request.
Provisioning is how SailPoint turns an access decision into a real change on a target system, creating an account, adding a role, removing an entitlement. It is the outbound half of identity governance, the point where policy becomes enforced reality, and understanding it end to end is essential for both building and debugging.
What triggers provisioning
Provisioning is always the result of a decision: birthright/role assignment during refresh, an approved access request, a lifecycle event (joiner/mover/leaver), or a certification revocation. Whatever the trigger, they converge on the same engine and pipeline.
The provisioning pipeline
- Plan compilation, build a provisioning plan describing the intended account and attribute changes.
- Policy evaluation, check the resulting state against SoD and other policy; a conflict can block or require an exception.
- Approvals, route work items and wait if sign-off is required.
- Execution, the connector applies the plan on the target system.
- Verification and audit, confirm via the next aggregation and record the transaction.
Automated versus manual provisioning
Where a read-write connector exists, provisioning is automated. Where it does not (some legacy systems), SailPoint raises a manual work item, or a ticket in a system like ServiceNow, for a human to make the change and mark it complete, then tracks it to closure. Most deployments mix both, and both are governed and audited identically.
Deprovisioning: the other half
Removing access is as important as granting it. Mover events should revoke old access, and leaver events should remove everything, starting with an immediate disable. Reliable deprovisioning is the single most valuable control for reducing orphaned-account and insider risk.
Reading provisioning problems
When access does not appear or disappear as expected, the provisioning transaction is your diagnostic: it shows whether a plan was compiled, whether policy blocked it, whether an approval is pending, or whether the connector failed (credentials, insufficient rights, network). Each stage leaves evidence, so you can pinpoint rather than guess.
Common pitfalls
- Assuming success without verifying the change on the target.
- Connector service accounts lacking rights to make the change.
- Mover events that only add access, never revoking the old.
Authoritative sources
- SailPoint IdentityIQ documentation — Provisioning and lifecycle manager reference
Authoritative sources
- SailPoint IdentityIQ documentation - Provisioning and lifecycle manager reference