What is recommended approach when usageLocation must be updated immediately before assigning Microsoft 365 licenses?

Question

We need to update a Microsoft Entra ID user’s usageLocation and immediately assign or modify Microsoft 365 licenses for the same user.

Our current sequence is:

PATCH /v1.0/users/{userId}
{
    "usageLocation": "US"
}

followed immediately by:

POST /v1.0/users/{userId}/assignLicense
{
    "addLicenses": [...],
    "removeLicenses": [...]
}

Sometimes the assignLicense request returns 400 Bad Request, indicating that the user has no valid usage location. However, the preceding PATCH request completed successfully. We assume this happens because the updated usageLocation has not yet replicated to the backend that processes license assignments.

Our current workaround is retry logic: when assignLicense returns 400 Bad Request after changing usageLocation, we retry the request several times.

We would like to know Microsoft’s officially recommended approach for this scenario:

1. Is retrying assignLicense after a 400 Bad Request the recommended solution for the replication delay?
2. Is there any supported API that can update usageLocation and assign licenses atomically?

We also tried combining both changes into a single request using the Microsoft Graph beta endpoint:

PATCH /beta/users/{userId}
Content-Type: application/json

{
    "usageLocation": "US",
    "assignedLicenses": [
        {
            "skuId": "..."
        }
    ]
}

The current beta documentation lists assignedLicenses among the properties that can be updated using PATCH /users/{id}:

https://learn.microsoft.com/en-us/graph/api/user-update?view=graph-rest-beta&tabs=http

However, the request returns:

Property 'assignedLicenses' is read-only and cannot be set.

The documented and working method for license changes remains:

POST /users/{id}/assignLicense

Could Microsoft confirm whether listing assignedLicenses as an updatable property in the beta Update user documentation is a documentation error, or whether additional requirements apply?

Answer 1

Microsoft details the design and expectations for Entra ID methods here: https://devblogs.microsoft.com/identity/designing-for-eventual-consistency-for-microsoft-entra/

Here's the short version:

What not to do

• Assume immediate visibility after a write
• Treat not found after creation as a permanent failure
• Use fixed sleep delays without retry logic
• Build workflows that depend on strict ordering across separate calls to Microsoft Entra