SailPoint provisioning

Provisioning is how IdentityIQ makes access changes happen in target systems, automatically and on request.

Quick answer

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.

Key takeaways

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 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.

Provisioning flow: from an approved request to a verified account change.

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

Want this with a live instructor and a lab tenant?

SailPoint IdentityIQ training →

Practice challenge

3 questions

Q1Provisioning is the process of?

Writing access changes to targets. Provisioning writes changes out; aggregation reads in.

Q2A structured request of account operations is a?

Provisioning plan. The provisioning plan describes the account changes to make.

Q3With no automated connector, IdentityIQ raises a?

Manual work item. A manual work item asks an admin to make and confirm the change.

Frequently asked questions

What does the term provisioning refer to in SailPoint?

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.

What is the place of provisioning in the joiner-mover-leaver lifecycle?

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.

What is worth remembering about provisioning in practice?

Whatever the trigger, they converge on the same engine and pipeline.

What tends to go wrong with provisioning?

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.

Want this taught live, with job support?

SailPoint Training is delivered live by working practitioners, with certification prep and placement support.

See SailPoint Training →