Retry many failed operations at once

When one configuration mistake fails many provisioning operations, fix the cause, then retry all of them with one confirmation from the Operations page. Owlie retries every failed operation your filter matches, against the current configuration, and records the result on each operation.

To retry a single failed operation or assignment, see Investigate a failed provisioning operation.

Example: retry what one sync run failed

A sync of your HR source added 40 people, and Owlie couldn't create their GitHub accounts because the provisioning profile had no mapping for a required attribute. You've added the mapping. To retry those 40 operations:

1. Open Integrations > Operations.
2. In the search bar, add Origin: Sync Run is followed by the run's ID. Open the run from Integrations > Sync Runs: its ID is the last part of the page address. To keep only the GitHub operations, also add Resource is GitHub.
3. Select Retry all matching. It's always on the page if you have permission to read and modify provisioning. With no filter beyond the default status filter, it retries every failed operation in your organization.
4. Check the dialog. Under Matching, it lists your filter with Status is Failed added: whatever statuses the list shows, only failed operations are retried. Below it reads "Up to 40 failed operations match."
5. Select Retry up to 40 operations.

Owlie retries each operation as you. Each retry uses your current configuration and continues from the step that failed. Steps that already succeeded are not repeated unless you edited that step, and the account is updated to your current configuration. There's no limit on how many operations one retry covers, and the retry carries on in the background if you leave the page. Closing the dialog without confirming changes nothing.

The count is "up to" because Owlie doesn't predict which operations it will refuse. An operation that can't be retried is still counted, and its row says why once its turn comes. Password changes, and operations whose failed Grants were already retried as a new operation, are never included.

If more operations match by the time you confirm, for example because the sync failed a few more, the dialog shows "More operations match now." with the new count. Nothing was retried. Check the count, then confirm again.

With no filter of your own, the dialog says it retries every failed operation in your organization. A filter of Status is Failed on its own covers the same operations. Check the count before you confirm.

Follow the retry batch

After you confirm, Owlie shows "Retry requested for 40 operations". The list switches to the batch: its filter becomes Retry Batch is followed by the batch ID, and it shows the batch's operations in every status. The Retry batch panel opens beside the list and counts where each operation stands. The counts update as operations change.

• Waiting to run: requested, not started yet. Owlie works through a batch in the background.
• Deferred, retrying: the attempt couldn't run yet, for example because another operation on the same assignment was still being prepared. Owlie tries again after a delay.
• Running and Fulfilled: the retry is under way, or done.
• Retried as a new operation: Owlie retried the operation's failed Grants as a new operation. The original operation stays failed.
• Refused: Owlie didn't retry the operation. Its row says why.
• Failed again: the retry ran and the operation failed again. Open it to read the new error.
• Cancelled: the operation was cancelled, for example because a newer change for the same access replaced it.

An operation that already had a retry requested keeps that earlier request and its batch, so the panel doesn't count it. The confirmation message says how many there were.

On each failed operation, the list's Retry column shows the request:

• Retry requested, with how long ago you asked.
• Deferred, retrying, with when you asked.
• Retry refused, with the reason, such as "This account hasn't been provisioned yet. Retry the provision first." The row shows the full reason and its code.

To list every operation refused for the same reason, filter on Retry Refusal Code.

A policy's failures are retried from the policy

When your filter pins one policy's operations, with Origin: Type is Policy and Origin: Reference ID is the policy's ID, or with Origin: Policy Wave, the dialog doesn't retry them. It names the policy, for example "Retry Engineering GitHub access from its rollout.", and offers Open the rollout. That opens the policy's Rollout tab, where Retry failed changes first decides again, for each affected person, whether the policy still grants the access, then retries their failed operations against the current configuration.

A filter that includes policy operations among others, such as Status is Failed on its own, retries them like any other operation. If the policy has released the assignment, that operation is refused with "This provision's assignment was released; provision again."

Choose what to retry

Each search filter reads as a chip in the search bar. These pick out a group of failures:

• Origin: Sync Run is a run's ID: the operations one sync run started.
• Origin: Review Campaign is a campaign run's ID: the removals that run's review decisions started. Open the run from its campaign: the ID is the last part of the page address.
• Origin: Type is Request with Created At on or after Oct 19, 2026: operations that access requests started since that date.
• Failure Code is a code: operations that failed the same way. A failed operation shows its code when you open it.
• Retry Batch is a batch ID: the operations of an earlier retry. The Retry batch panel shows the ID. Retry Requested At finds requests that are still waiting to run.

You can combine any of these with Resource is or Identity is to narrow the group.

Limits

• A hook that already ran isn't sent again unless you edited it. A hook whose configuration is unchanged is not re-sent, even when the data it reads has changed. The account itself still gets your fix. If the hook sent a wrong value to another system, that value stays there: to re-send the hook, edit it before you retry. Once the operation succeeds, editing the hook doesn't rerun it for that account.
• A completed approval or timer isn't asked again unless you changed it, changed a step before it in the same list, or added or removed another approval or timer in that list.
• A step whose result Owlie couldn't confirm runs again. For example, a hook that timed out is sent again on the retry.
• A fulfillment function that already ran is usually called again. The retry calls it with your current configuration if anything changed since it ran, or if the provisioning profile has hooks for the operation. It's skipped only when nothing changed and there are no hooks. A function whose call timed out is called again on the retry.
• Owlie doesn't create a second account. If an earlier attempt may have created the account, the retry looks for it and uses it once it can confirm it's the same account. When it can't confirm it, for example on a system with no stable account ID and no adoption rules, the operation fails with account_identity_unconfirmed instead. The generated username of such an account is kept.
• A retry can't be cancelled. Operations still waiting in a batch are retried unless a newer change for the same access replaces them first.
• Only failed operations are retried. Operations that are still in progress, cancelled, or fulfilled are left alone.