Microsoft Entra eventual consistency: fix Graph app-only automations before they break

A successful write in Microsoft Entra does not guarantee that the next read sees it. If you have app-only Microsoft Graph automation that does Create then immediate Read, Assign, or Validate, this is the kind of change that quietly breaks runbooks while everything still looks "healthy" from the platform side.

Microsoft is being direct about the design now: Entra is eventually consistent, especially for application-only access. Writes are accepted first and replicated asynchronously across replicas. During that window, a newly created object can return 404 Not Found, and a recently updated property might not yet show up on a read. That is not an outage. That is the platform behaving as designed.

For engineers, the important part is not the theory. It is the operational consequence: if your automation assumes implicit read-after-write consistency, your script is fragile today. This is especially common in background jobs, provisioning flows, and tenant automation built with Graph, PowerShell, Azure Functions, or Logic Apps. If that sounds familiar, this is exactly the sort of workflow I would review in an AI and automation audit before it fails at scale.

What actually breaks

The failure pattern is predictable:

Microsoft also separately documents the 404-after-create problem in Graph management scenarios and explicitly says replication can take several minutes. The recommended fix there is also retrying, doubling the wait time when needed.

My take: this is the right distributed-systems choice for Microsoft, but a bad surprise for customers who built automation around old observed behavior. Those are different things. At Entra scale, eventual consistency is sensible. But if you learned from years of scripts that "POST then GET usually works," your estate may now depend on an implementation detail you never got a contract for.

What to change in your scripts

The big rule is simple: stop reading just to reassure yourself.

In practice, I would change four things:

• Trust successful write responses and store the object ID or properties they return.
• Remove GET-right-after-POST or PATCH where it is only used as confirmation.
• Replace fixed sleeps with retry logic and exponential backoff.
• Make each step idempotent so retries do not create duplicates or accidental side effects.

Where a read is unavoidable, use the Graph patterns that are meant for eventual consistency. Microsoft Graph documents the ConsistencyLevel: eventual header for advanced query scenarios on directory objects, including PowerShell examples such as:

Get-MgUser -Filter "accountEnabled ne true" -CountVariable CountVar -ConsistencyLevel eventual

That header is not a magic fix for replication delay, but it is a clue about how Graph expects you to think about directory reads: not as strongly consistent transactions.

Here is the PowerShell pattern I would use in runbooks instead of Start-Sleep:

function Invoke-WithRetry {
    param(
        [Parameter(Mandatory)]
        [scriptblock]$Operation,
        [int]$MaxAttempts = 6,
        [int]$InitialDelaySeconds = 2
    )

    $attempt = 0
    $delay = $InitialDelaySeconds

    while ($attempt -lt $MaxAttempts) {
        try {
            return & $Operation
        }
        catch {
            $attempt++
            if ($attempt -ge $MaxAttempts) { throw }
            Start-Sleep -Seconds $delay
            $delay = $delay * 2
        }
    }
}

$app = New-MgApplication -DisplayName "demo-eventual-consistency-app"
$appId = $app.Id

Invoke-WithRetry -Operation {
    Get-MgApplication -ApplicationId $appId -ErrorAction Stop
}

What this changes in practice

Most orgs will not notice this in interactive admin work. Automation estates will. The risky area is service principal driven workflows: provisioning, access assignment, app registration pipelines, identity governance jobs, and anything chaining Entra object creation with downstream steps.

The second-order effect is governance: brittle retry-free identity automation tends to fail half-way through, leaving orphaned apps, partial group membership, or missing role assignments. That is not just an engineering nuisance; it becomes a security and accountability issue. An agent or runbook should not get a blank check to keep retrying blindly either, which is why I would pair these fixes with least-privilege review and tighter Microsoft Copilot and AI agents or custom MCP servers boundaries where identity actions are involved.

Bottom line: if your Entra automation reads immediately after it writes, assume it is wrong and refactor it now. Trust the write response, retry transient 404s, and stop using sleep as a control plane.