Provisioning failed
Quick answer
Provisioning failures usually come from connector credentials, target-side errors or policy blocks. Check the provisioning transaction and connector logs first.
Key takeaways
- Symptom: A provisioning operation did not complete on the target system.
- Most likely causes
- Step-by-step fixes
- How to prevent recurrence
A provisioning operation did not complete on the target system, an account was not created, a group not added, an entitlement not removed. Because provisioning is the last step of a long chain, the failure could be anywhere from policy to the connector, so a methodical read of the evidence is essential.
Start here: read the evidence
Open the provisioning transaction for the request. It records the compiled plan, any policy decisions, approval status and the connector result, including the actual error the target returned. This single artifact usually tells you exactly where the flow stopped.
Likely causes, in order
- Connector credentials expired or wrong, the service account cannot authenticate to the target.
- Insufficient rights, the service account authenticated but lacks permission to make the change (a very common "insufficient access rights" error on AD).
- Policy block, a separation-of-duties violation quietly prevented the change.
- Pending approval, the change is not failed but waiting.
- Network/firewall, the task/VA host cannot reach the target.
How to fix it
- Read the provisioning transaction to identify the failing stage.
- Verify the connector service account credentials and its rights on the target for this operation.
- Check for policy violations on the request.
- Confirm no approval is still pending.
- Fix the root cause and retry, then confirm the change on the target via the next aggregation.
Preventing recurrence
Monitor provisioning transactions for failures rather than assuming success; grant connector service accounts exactly the rights they need; and alert on repeated connector-auth failures so expiring credentials are caught before they break provisioning.
Common pitfalls
- Guessing instead of reading the task/transaction result, which usually names the cause.
- Fixing the symptom, not the root cause, so it returns.
- Changing several things at once, so you cannot tell what worked.
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
Where do you start diagnosing?
- A. Expired/incorrect connector credentials or a target-side rejection.
- B. The provisioning transaction and connector logs, which carry the actual error.
- C. Yes, a policy violation can block provisioning.
Show answer
B. The provisioning transaction and connector logs, which carry the actual error.
The provisioning transaction and connector logs, which carry the actual error.
Common cause?
- A. Yes, a policy violation can block provisioning.
- B. Expired/incorrect connector credentials or a target-side rejection.
- C. The provisioning transaction and connector logs, which carry the actual error.
Show answer
B. Expired/incorrect connector credentials or a target-side rejection.
Expired/incorrect connector credentials or a target-side rejection.
Can policy cause it?
- A. The provisioning transaction and connector logs, which carry the actual error.
- B. Expired/incorrect connector credentials or a target-side rejection.
- C. Yes, a policy violation can block provisioning.
Show answer
C. Yes, a policy violation can block provisioning.
Yes, a policy violation can block provisioning.