Retry or remove a failed Grant

When a connected system refuses one Grant, Owlie records the failure on that Grant and carries on with the rest of the change. The other Grants are written, and later changes to the account aren't held up. The failed Grant waits until you fix the cause and retry it, or remove it.

For example, if an operation adds a role and two groups and the connected system refuses the role, the groups are still added and the role is marked failed with the system's reason.

A Grant can also fail without being sent. When a Grant needs other access first, such as the organization membership an Auth0 organization role needs, and that access failed or is missing from the connected system, Owlie marks the Grant failed instead of sending a write it knows will be refused. Its row reads "Failed because the access it needs failed" or "Failed because the account lacks the access it needs", and its details name that access.

A Grant can also fail after Owlie added it, when the connected system's listing stops showing it. See When the connected system stops listing access Owlie added.

Owlie handles a Grant this way only in these cases. A failure that may have reached the connected system, or a connection problem, still fails the whole operation. For those, see Investigate a failed provisioning operation.

Where failed Grants show

Open the identity, then the assigned resource on its Resources tab.

• On the Access tab, under Direct grants, a failed Grant shows a Failed badge and the connected system's reason.
• Above the list, a banner counts the failed Grants, for example "2 Grants failed.", with Retry failed Grants.
• The assigned resource's side panel shows Failed Grants with the count, next to the applied version.
• On the Operations tab, an operation that also made other changes completes and lists the failed Grant in its results. An operation whose every Grant failed is marked failed.

When Grants fail, Owlie raises one admin alert per integration and failure code, such as "Auth0 refused access (PRECONDITION_FAILED)", and counts the assigned resources affected. One code across many people often points at a configuration problem. The alert resolves itself once no Grant is failing with that code.

Until you act, Owlie doesn't try the failed Grant again. It stays part of what the person should have, so access the account already holds through it isn't removed. If a later sync finds the Grant in the connected system, the failure clears on its own.

When the connected system stops listing access Owlie added

Sync reads each account's access from the connected system. When a complete sync no longer lists a Grant Owlie added, Owlie adds it again, once. If a complete sync taken at least the integration's listing delay after that still lacks it, the Grant fails on its own. Sometimes Owlie can't add it again, for example while access the Grant needs can't be read. The delay then counts from when the Grant went missing, so the Grant still fails on its own instead of waiting forever:

• "Failed because the application no longer lists it" (code UNCONFIRMED_BY_READ). The Grant's details say whether Owlie added it again first. If it did, the connected system accepted the write but doesn't show the access: check how it lists that access, or whether something removes it again. If it couldn't, fix what kept it from adding the access, such as the access the Grant needs, then retry.
• "Failed because its target is gone from the application" (code TARGET_MISSING). The group, role or other target the Grant points to is gone from the connected system's listing, so Owlie doesn't add the Grant again. Restore the target, or remove the Grant.

The alert names the integration, for example "Auth0 does not list access Owlie added" or "Auth0 no longer lists what access points to". When a later sync lists the Grant again, the failure clears on its own.

Whether sync adds the access back right away depends on the sync's assignment policy. With Enforce Owlie, the sync that finds the Grant missing starts the repair. With any other policy, Owlie adds it back the next time it provisions the account.

Change the listing delay

Some connected systems take a while to list access they just accepted. The listing delay is how long Owlie waits, after adding the Grant again (or, when it couldn't, after the Grant went missing), before it treats a missing Grant as failed. It's 15 minutes unless you change it.

1. Open the integration.
2. Under Listing delay, enter the number of minutes, from 1 to 1440 (one day). Leave it empty for the default.
3. Select Save delay.

The delay counts from when Owlie added the Grant again, or from when the Grant went missing if Owlie couldn't add it, to when the sync that still lacks it started.

Fix the cause and retry

1. Read the reason on the failed Grant. It comes from the connected system. For a Grant that failed on the access it needs, open the Grant's details to see which access.
2. Fix the cause in the connected system or in the resource's configuration. If the Grant needs other access first, make sure that access can be added too.
3. Retry from the place that fits:
   • One Grant: on the Access tab, select the Grant to open its details, then select Retry. The row reads "Retry queued" until the retry finishes.
   • Every failed Grant on the assigned resource: select Retry failed Grants, then Retry Grants.
   • Every Grant behind an alert: open Alerts, show the alert's details, select Retry these Grants, then Retry Grants. Owlie retries each affected assigned resource separately and lists any it couldn't retry, with the reason. It takes up to 50 assigned resources at a time; when more are left, the dialog says how many, and Run again continues with the next ones.

You need permission to modify provisioning. Retry works the Grant out again from the current configuration, so a cause that isn't fixed makes it fail again. Saving a configuration change doesn't retry anything on its own.

If a Grant failed because access it needs failed, retrying the Grant also retries that access, and Owlie writes the access first. You don't need to retry the two separately. If the access it needs is missing instead, for example because someone removed it in the connected system, Retry fails again until that access exists. Add the access first, then retry the Grant.

Some failures are reported by an operation rather than recorded on the Grant, for example when the whole operation failed. Those rows offer Open operation to retry instead of Retry. It opens the operation so you can retry it there; see Investigate a failed provisioning operation.

Remove a Grant instead

If the person shouldn't have the Grant, remove it. On the Access tab, any Grant Owlie manages and the person should have offers Remove: applied, never applied, scheduled or failed. Select it, then confirm with Remove grant.

• A Grant that never reached the connected system, such as a failed one, is removed in Owlie without contacting the connected system.
• If a policy still grants it, the Grant is kept, and the row says "Kept: a policy still grants this".
• Access the Grant brought with it, such as an organization membership, is removed too unless something else still holds it. See required access.
• Removing a scheduled Grant also cancels the scheduled operation that would add it, including anything else that operation adds.