Restoring a deleted user flow

A deleted user flow is one of the sharper failures in a customer identity tenant: sign-up and sign-in stop working for every application that referenced it, and Microsoft Entra has no recycle bin for user flows — they are hard deleted the moment they are removed. This article covers what breaks, how to restore the flow from a recovery point, and what to check before you call it fixed.

Why this one hurts

User flows are not on Microsoft's soft-delete list. Users, groups, applications, Conditional Access policies and named locations all enter a 30-day recycle bin when deleted. User flows do not — there is no Deleted items view to recover them from, and Microsoft Support cannot restore them either. See Does Microsoft back up Microsoft Entra External ID? for the full list of what is and isn't covered.

The impact is immediate and total for the affected application. The flow defines which identity providers appear, which attributes are collected at sign-up, and which claims are returned. Without it, users are not inconvenienced — they simply cannot get in.

A user flow also does not stand alone. It references identity providers, user attribute definitions, and the applications associated with it. Recreating it by hand means recreating those relationships correctly, which is why a restore that understands dependencies matters more here than almost anywhere else.

Before you restore: find the right recovery point

Open Recovery points and choose the affected tenant. Usually you want the most recent recovery point taken before the deletion.

If you are not certain when the flow disappeared, use the Drift page to compare recovery points against the live tenant. A deleted user flow shows up as a Missing row — the object is present in the recovery point and absent from the tenant. Comparing successively older recovery points narrows down when it vanished, and the last one where the flow is still present is the one to restore from.

Your Entra audit log will also record a delete event for the object, which is worth checking to understand how it happened.

Running the restore

Select the recovery point and choose Restore to open the wizard. The full mechanics are covered in Restoring from a recovery point; the parts that matter for this scenario are:

Resources. Restrict the restore to what you actually need. If only the user flow was deleted, select just that resource type rather than the whole tenant — a narrower restore is faster to review and easier to reason about.

Restore order is handled for you. EIDGuard restores in dependency order, so attribute definitions and identity providers are restored before the user flows that reference them. That ordering is the reason a selective restore of a user flow works even when the objects it depends on were also affected.

Mode. Leave it on Missing only, the default. The flow no longer exists, so it will be recreated; anything still present in the tenant is left untouched. Missing-only is the correct mode for an accidental deletion, and it needs only the Operator role. Full mode — which also overwrites existing objects — is for rolling back unwanted changes, not for restoring something that is simply gone.

Preview. Run the read-only preview (WhatIf) and read the action list before applying anything. You should see a create action for the user flow and, if they were also missing, for the attributes and identity providers it depends on. If you see updates to objects you did not expect to touch, stop and narrow the resource selection.

Apply. Applying starts the restore job. Watch it under Jobs, where it also stays as an audit record.

After the restore

Two things need your attention before you consider the incident closed.

Check the manual actions list. Some material cannot be exported from Microsoft Graph and therefore is not in any backup. For a user flow restore the relevant one is identity provider client secrets: a recreated identity provider comes back with a placeholder secret, and you need to paste the real value from the provider's console — Google, Apple, or whichever federation is involved. The restore results page lists every such follow-up explicitly under Manual actions required.

Test an actual sign-in. Restoring the object is not the same as confirming the journey works. Run a real sign-up and sign-in against the application that uses the flow, exercising each identity provider it offers. Check that the expected attributes are collected and the expected claims come back.

If Conditional Access policies were restored alongside it, note that EIDGuard always recreates CA policies disabled, so a restored policy cannot lock anyone out before you have reviewed it. Re-enable each one deliberately after checking its assignments.

If you don't have a recovery point

If the flow was deleted and no backup covers it, there is no recovery path — neither in the portal nor through Microsoft Support. Rebuilding means reconstructing the flow's identity providers, attribute collection, claims, and application links from documentation or memory, then re-testing every application that used it.

The practical lesson is that the window to prepare closes before the incident, not after. Backing up daily and verifying nightly means the worst case is losing a day of changes rather than an afternoon of reconstruction under pressure — see Drift detection and daily operations.