Provisioning flow
Quick answer
A provisioning plan is compiled from a requested change, checked against policy, approved, then executed on the target via a connector.
Key takeaways
- Purpose: turn an approved access decision into a real change on a target system
- Trigger: A request, role change or lifecycle event
- Outcome: The target account or entitlement is created, modified or removed
- Where it fits in the SailPoint architecture
The provisioning flow is how an access decision inside IdentityIQ becomes a real change on a target system, an account created in Active Directory, a role added in SAP, an entitlement removed after a certification. Understanding each hop is invaluable, because when access does not appear (or does not disappear) as expected, the fault is almost always at an identifiable point in this chain.
What starts a provisioning flow
Provisioning is triggered by a decision, never at random. Common triggers are a birthright/role assignment during identity refresh, an approved access request, a lifecycle event (joiner/mover/leaver), or a certification revocation. Whatever the source, they all converge on the same pipeline.
Step by step
- 1. Plan compilation. IdentityIQ builds a provisioning plan, a structured description of the intended change: which account on which application, and which attributes to add, remove or set.
- 2. Policy evaluation. The plan's resulting state is checked against policy, most importantly separation-of-duties. A violation can block the change or force an exception approval.
- 3. Approvals. If the change requires sign-off, work items are generated and routed to approvers; the flow pauses until they respond.
- 4. Execution. The relevant connector applies the plan to the target system, creating, modifying, enabling or disabling the account and its entitlements.
- 5. Verification and audit. The result is recorded; the next aggregation confirms the change actually took effect, and the audit trail captures the whole transaction.
Provisioning modes
Not every target can be changed automatically. IdentityIQ supports automated provisioning through a read-write connector, and manual provisioning where it raises a work item (or a ticket in a system like ServiceNow) for a human to make the change and mark it done. Many deployments are a mix, automated where connectors allow, manual for legacy systems.
Where the flow breaks, and how to read it
The provisioning transaction is your primary diagnostic. If access did not appear, check in order: was a plan compiled at all (did the trigger fire?), did policy block it, is an approval still pending, or did the connector fail (bad credentials, insufficient rights on the target, network)? Each stage leaves evidence, so you can pinpoint the failure rather than guess.
Common pitfalls
- Assuming success without verification, always confirm the change on the target via the next aggregation.
- Connector service accounts lacking rights to make the change, a frequent "insufficient access" failure.
- Silent policy blocks, a SoD violation quietly stopping provisioning that operators do not think to check.
Want to learn this properly?
Our live, instructor-led SailPoint Training covers this hands-on, with real projects and a certification path.
Check your understanding
What triggers the provisioning flow?
- A. The target account or entitlement is created, modified or removed
- B. Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.
- C. A request, role change or lifecycle event
Show answer
C. A request, role change or lifecycle event
A request, role change or lifecycle event
What is the outcome of the provisioning flow?
- A. Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.
- B. The target account or entitlement is created, modified or removed
- C. A request, role change or lifecycle event
Show answer
B. The target account or entitlement is created, modified or removed
The target account or entitlement is created, modified or removed
Where does this flow run?
- A. The target account or entitlement is created, modified or removed
- B. Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.
- C. A request, role change or lifecycle event
Show answer
B. Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.
Inside the IdentityIQ engine, coordinated by tasks, connectors and the provisioning subsystem.