Graph API patch requests on 'place' related entities results in errors

All four behaviors are consistent with current Microsoft Graph Places semantics and recent changes, not with anything in the request payloads alone.

1. Building wifiState and desk heightAdjustableState errors

Recent changes introduced new state properties on place types:

• wifiState on building
• heightAdjustableState on desk

These are modeled as state enums. The error messages

• WifiState cannot be set to Unknown state.
• HeightAdjustableState cannot be set to Unknown state.

indicate that when issuing a PATCH, the service is treating the missing values as an attempt to set these properties to an Unknown enum value, which is not allowed on update.

Create succeeds because the properties are optional at creation time, but update enforces a valid, non-Unknown state.

Workaround:

• When PATCHing a building, always include a valid wifiState value.
• When PATCHing a desk, always include a valid heightAdjustableState value.

This is consistent with the pattern shown in the update examples where the PATCH body always includes a valid type and properties, for example:

PATCH https://graph.microsoft.com/v1.0/places/530f7900-8063-4daf-9cc1-168cb3ac26e9
Content-Type: application/json

{
  "@odata.type": "microsoft.graph.desk",
  "mode": {
    "@odata.type": "microsoft.graph.dropInPlaceMode"
  }
}

2. Room/workspace placeId cannot be updated

Recent changes to the Places model specify that:

• The base place type no longer has placeId.
• Only room and workspace retain a placeId property.

The error Place id cannot be updated. occurs because placeId is a server-managed identifier and is immutable. Even if the request body does not explicitly change placeId, sending it in the PATCH payload can be interpreted as an attempt to update it.

Workaround:

• When PATCHing room or workspace, omit the placeId property entirely from the request body. Only send the properties that need to change.

3. Building ServiceMetadata cannot be changed via API

The error ServiceMetadata cannot be changed via API. indicates that some internal, service-managed metadata on the building resource is being treated as changed in the PATCH request. This aligns with the general rule that certain system properties are read-only and cannot be modified via Graph.

The fact that:

• PATCH works on the same day the building is created, but
• fails 1+ days later

suggests that the service populates or updates internal metadata after creation (for example, background processing or synchronization), and subsequent PATCH requests that include that metadata (even unchanged) are rejected.

Workaround:

• Use minimal PATCH payloads: send only the properties that must be updated, and omit any service-managed or read-only properties.
• Ensure the request body matches the patterns in the official examples, which only include the type and the fields being changed, for example:

PATCH /places/{id}
Content-Type: application/json

{
  "@odata.type": "microsoft.graph.building",
  "tags": ["most popular building"]
}

4. Permissions and roles

Ensure the correct permissions and roles are configured, as Places updates require:

• Place.ReadWrite.All (delegated or application) for /places/{id} PATCH.
• For delegated (work/school), at least the Exchange Administrator Microsoft Entra role.
• For application permissions, the TenantPlacesManagement and MailRecipient RBAC roles in Exchange Online.

Although the documentation notes a known issue where updates may succeed without these roles but behave unexpectedly, configuring them correctly reduces the chance of inconsistent behavior.

5. Where to report

These behaviors—especially the Unknown state enforcement and the delayed ServiceMetadata error—are service-side issues. They should be reported through official Microsoft support or the Microsoft Q&A forums for Microsoft Graph/Places so that the product group can confirm whether they are bugs or by-design constraints.

In the meantime, the practical guidance is:

• Always include valid wifiState and heightAdjustableState values when updating buildings and desks.
• Never include placeId in PATCH bodies for rooms and workspaces.
• Use minimal PATCH payloads that only contain the properties being changed and the correct @odata.type.

References:

• Working with the Places API in Microsoft Graph
• Update place
• Microsoft Graph what's new history