Failed Jobs Queue
No auto-tasks — provisioning failures land as a tracked provisioning job with a retry gate.
Failed Jobs queue (no auto-tasks)
The platform no longer creates a manual provisioning task on a provisioning failure. Instead, it records a provisioning job (the tracked target write) with status=FAILED, a structured failure_detail, and a config_snapshot.
The IAM team triages these in the Failed Jobs tab of Provisioning Ops, fixes the root-cause configuration (a mapping, lookup, or expression), and clicks retry.
Retry is gated on a configuration change
POST /provisioning-jobs/{id}/retry refuses (HTTP 409) when the current configuration-snapshot hash is equal to the baseline captured at failure time. The reason: otherwise the IAM team could get away with "click retry until it works" and skip the root-cause analysis.
ℹ Good to know
This is the anti-quick-fix invariant. There is NO force-bypass — if the fix really lies on the target side and not in the platform configuration, mark the job as
won't_fixwith a justification.
Mark won't-fix — admin only, justification required
For edge cases (legacy data, customer-specific exceptions) an iga_admin can mark a job as WONT_FIX. This requires a justification string, which is stamped into the immutable audit trail for compliance. An iga_op_admin has retry rights only, not won't-fix rights.
Further reading: