There are two likely causes for a request to end with a status of Failure. One is more common, and the other is rare, as detailed below.
Common: a requested resource no longer exists
The more common cause of a request failing, and the first thing you should check, is that the requested Target or Permission no longer exists in the requested System.
Examples:
You requested to get permission set ABC for AWS account 12345, but the permission set ABC no longer exists in AWS account 12345.
You requested to get access to database XYZ in PostgreSQL server acme.example.net, but the database XYZ no longer exists.
How can this happen?
Understanding this requires diving deeper into how Axiom works (also see timeline diagram below):
The list of available Targets and Permissions is collected in a process we call Scan, which by default runs once every 24 hours, for each System. Learn more
Any Target or Permission found during the scan, is available for requests (assuming the user has Scope).
If a Target or Permission is removed from the System, Axiom will not know about it until the next Scan completes.
If an access request was made before the next scan, then the request creation will succeed.
If the Target or Permission have actually already been removed from the selected System, then once approved, the request will end up with status Failure. This can happen in one of two ways:
If the approval happens after the next scan has run, then Axiom can re-validate the existence of the Target and Permission, and can immediately fail the request.
If the approval happens before the next scan has run, then Axiom does not know that that the Target or Permission no longer exist, and Failure will happen during the provisioning phase of the request lifecycle.
Request life cycle and provisioning
Once a request is approved (by a human or an automated Workflow), if it passes the re-validation described in #1 above, then its status changes to Approved. This is when the actual provisioning process starts.
Provisioning is the process of communicating with the selected System, and actually granting access to the Principal selected in the request (access to the requested Target, with the requested Permission). Provisioning typically takes about 30 seconds, but can sometime take longer.
If the Target or Permission have been removed from the System since Axiom last scanned it, then the provisioning will fail, and the request status will change to Failure.
Rare: Axiom does not have sufficient permissions
Requests can also fail in the provisioning stage if Axiom does not have the required permissions.
This can happen if the permissions given to Axiom during the integration were wrong, or were modified after the integration.
Need more help? Open a support ticket