Microsoft Graph AuditLogs: Clarification on Split License Assignment Events for Large License Bundles

Question

I am seeking an official clarification regarding the behavior of Microsoft Graph Audit Logs when processing large license assignment or removal events.

Observed Behavior

When assigning or removing large license bundles (for example, Microsoft 365 E5, E3 with many add-ons, or custom license packs containing 50+ service plans), we observe the following behavior in the AuditLogs endpoint:

• The resulting audit event payload becomes very large due to extensive assignedLicenses / servicePlans data.

Microsoft Graph appears to enforce an internal size limit per individual audit log record.

When this limit is exceeded, the audit event is automatically split into multiple sequential records (behavior observed consistently since mid-2024).

Each split record contains:

The same or closely related correlationId

Sequence metadata under extendedProperties, such as:

"id" – shared identifier across all parts

`"seq"` – sequence number (e.g., `"2"`)

`"c"` – total expected chunks (e.g., `"4"`)

`"b"` – escaped JSON fragment of the original payload

Impact

Due to this behavior:

A single audit log record never contains the full license assignment details for large license changes.

Parsing a single event always results in incomplete or invalid JSON.

Correct reconstruction requires:

Querying all related events using correlationId (or time + activity)

  Sorting by sequence number
  
Concatenating the `"b"` fragments
     
Parsing the reconstructed JSON

This creates architectural challenges for backend systems, as no single API call or record can reliably return the complete details of a license change.

Workarounds Evaluated

Increasing $top / pagination → does not affect per-record payload size

Using /beta endpoints → same splitting behavior

Aggregation service → high complexity, latency, and reliability concerns

Clarification Requested

Could Microsoft please confirm:

Whether this splitting of oversized audit log events is an intentional and permanent design decision

If there is any supported way to retrieve the entire license assignment payload in a single audit log record

Whether Microsoft recommends a best-practice approach for consumers who must process large license change events reliably

At present, this appears to be an unavoidable platform limitation rather than an implementation issue on the client side, and we would appreciate official guidance or confirmation.

Please find the supporting screenshots for the above concern. The same has also been confirmed by sequentially concatenating the 'b' attribute based on the 'seq' attribute.

---

Moved from Microsoft 365 and Office | Other

Answer 1

It is intentional and has been around for years now. Here are my notes on it, along with sample code you can use: https://michev.info/blog/post/6168/sequence-events-in-the-entra-audit-log-and-how-to-work-with-them

Before these changes were implemented, it was not uncommon to have audit log events with broken (trimmed) JSON payload, due to the inherent length limits. This approach basically avoids that, at the cost of adding some additional overhead on the "client" side.