Managing external identities to enable secure access for partners, customers, and other non-employees
Hey @Manuel Tospann, it looks like your users were hitting AADSTS90072 (“user … from identity provider ‘mail’ does not exist in tenant …”) because the External ID tenant didn’t have those accounts yet and B2C’s sign-up/user-flow step that would normally provision them failed to complete. Since the errors only showed up between 12:20–12:40 UTC, it was almost certainly a transient glitch in the External ID provisioning pipeline (for example, a brief service hiccup or throttling on the Graph-API call that writes the guest/local user).
Here’s how you can drill into the “why” and get more detail on exactly what went wrong:
- In the Azure portal, switch to your Entra External ID (B2C) tenant.
- Under Monitoring → Sign-up logs, filter by the timestamp (2026-02-27T12:37:26Z) or paste in the Correlation ID/ Request ID that you copied from the error page.
- Review the log entry for that request and look for an inner-error or failure code on the “create user” operation.
- If you haven’t already, click Enable flagging on the error page and re-run it within 20 minutes. That lifts the logging level so you get a full diagnostic trace.
- As a Global Admin, you can also use the Sign-in Diagnostics blade: • Go to Azure AD → Diagnostics → Launch Diagnostic • Search by Correlation ID or Request ID and review the step-by-step call-stack.
Possible root causes for a short burst of AADSTS90072 errors:
- A transient outage or throttling between the External ID user-creation pipeline and Microsoft Entra’s Graph service
- A brief networking or region outage in the control plane
- Hitting a provisioning quota for guest accounts
- An auto-update or policy change in your custom user flow around that time
To rule out broader service issues, check Azure Service Health for any incidents in the same UTC window in the region where your External ID tenant lives.
If the logs don’t reveal an obvious root cause, let me know:
- Any modifications to your user-flow or IdP metadata right before 12:20 UTC?
- Whether you saw any throttling or “too many requests” errors in the sign-up logs?
- If this has recurred at all or was purely that one 20-minute window?
Hope that helps you pinpoint what tripped up the user-provisioning step!
References
Let us know if you need further assistance.