At a glance
A manager approved removal of an obsolete permission. The application rejected the change. Both facts can be true, and a useful governance record must show both.
- Report the intended and observed access state separately.
- Assign failures to an owner who can resolve them.
- Check the result before retrying an ambiguous operation.
Understand which part failed
At fictional Stonefield Services, an employee’s transfer completed in the workforce system. The connected application kept an old group membership because its integration account no longer had permission to remove it. The source event was valid; the execution path failed.
Distinguish collection failures from change failures. A failed read can leave reviewers using an old inventory. A failed write can leave the wrong access in place. The response should reflect the business consequence, not just an error category.
Make the exception actionable
| Exception detail | Why operations needs it |
|---|---|
| Identity and target account | Identifies the object affected. |
| Intended change | Shows what the authorised outcome should be. |
| Last known state and time | Explains what is currently understood. |
| Failure category | Helps identify the resolving team. |
| Owner and escalation | Prevents the issue staying in an unattended queue. |
Keep credentials and unrelated personal information out of routine error messages. Give the resolving team access to appropriate diagnostic information through the approved support process.
Retry with a clear understanding of state
A timeout does not always mean the action failed. The target may have processed it before the response was lost. Check the current state or the integration’s supported duplicate-handling behaviour before repeating an operation that could create a second account or unintended assignment.
SCIM’s protocol specification defines operations and error responses for identity resources. An integration still needs to interpret responses and target behaviour correctly; using a standard does not remove the need for operational testing. IETF RFC 7644: SCIM Protocol.
Define retry limits and escalation. An endless retry loop can hide a permanent mapping or authorisation problem while the business continues to rely on the wrong state.
Close against verified access
After recovery, confirm the target account or entitlement state and attach the result to the exception. Do not close the issue merely because connectivity is restored. The originally requested change may still be outstanding.
IGAX’s published connectors, workflows and audit-reporting features provide relevant building blocks for this process. During implementation, document what each connection can read and change, how errors surface and which actions require manual intervention.
Review recurring failures. Repeated mapping problems may indicate an application change; repeated permission failures may indicate an unsuitable integration account or change process. Fixing the cause is more valuable than repeatedly clearing the queue.
References
Primary guidance used for the specific points cited above. The examples, templates and recommended working practices are AIdentX editorial guidance.
Sources reviewed September 2026.
Published by AIdentX Editorial. Illustrative scenarios are fictional and do not represent customer results.