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

Question

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

Mullai Rajan 20

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.

2 answers

Your answer

Answer 1

Hi @MullaiRajan,

Welcome to Microsoft Q&A, and thank you very much for reaching out to us.

Note that as a Q&A moderator, I don’t have access to your tenant configuration, and my testing environment is limited. So I can only assist based on publicly available documentation and research. That said, I will try to assist you as much as possible.

From my research, I couldn’t find any Microsoft documentation that explicitly describes the “event splitting” behavior you’re observing or any stated internal per-record size limit for individual audit log records, so I’m unable to confirm whether the behavior is intentional or not.

That said, I did further research and found an external article that discusses AuditLogs Graph behavior similar to what you’re seeing. Feel free to check it out here.

Note: Microsoft is providing this information as a convenience to you. These sites are not controlled by Microsoft, and Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please ensure that you fully understand the risks before using any suggestions from the above link.

For a workaround, unfortunately, I couldn’t find a supported method to return the full license assignment payload in a single audit log record.

For a best-practice approach to retrieving audit data regularly and at scale, according to Microsoft documentation, Microsoft suggest using the Office 365 Management Activity API, which provides the scalability and performance needed to retrieve millions of audit records on an ongoing basis.

User's image

This summary is based on my findings from the community and several relevant threads. That said, it may not fully or accurately reflect the specific behavior you are experiencing.

To help you reach your goal more effectively, I recommend posting your question on the Microsoft Tech Community. It is a a great platform for in‑depth technical discussions and for engaging with engineers and practitioners who have hands‑on experience. You may also find others who are encountering the same behavior or discover potential workarounds relevant to your scenario.

Another option is to open a ticket through Microsoft Developer Support for further assistance. Their engineers are best positioned to investigate issues at the product level and provide accurate, authoritative guidance when behavior falls outside what is documented or expected.

Please note that Developer Support works through paid support tickets, either via an active support plan or a one‑time purchase. The benefit of this route is that your case can be reach directly to the Microsoft Product Group, which includes the engineers and developers who build and maintain the feature or service in question. I suggest using this option only if the issue becomes too disruptive or business‑critical.

Thank you for your understanding.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Mullai Rajan 20 Reputation points

2026-01-14T09:29:22.1533333+00:00

Hi @Kha-N ,

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.
Kha-N 7,070 Reputation points Microsoft External Staff Moderator

2026-01-14T09:50:57.18+00:00

Hi @MullaiRajan,

Thank you very much for your update and observation.

While this aligns with the behavior described in the external thread, I unable to find official Microsoft documentation that confirms the behavior you are observing. And with limited testing environment, I’m unable to formally validate this scenario and can only rely on the available documentation and publicly supported resources mentioned earlier. I also can’t speak on behalf of Microsoft without official documentation to support the claim.

For this reason, as mentioned above, I recommend posting the question in the Microsoft Tech Community to connect with other users who may be experiencing the same behavior and to explore potential workarounds. Or, if possible, you may consider reaching out to Microsoft Developer Support, as they can engage the Microsoft Product Group who build and maintain the feature or service to further investigate and provide authoritative guidance.

Thank you for your understanding.

Answer 2

The behavior you are observing with Microsoft Graph Audit Logs regarding the splitting of large license assignment or removal events into multiple records is not explicitly documented in the provided context. Therefore, I cannot confirm whether this is an intentional design decision or if there is a supported way to retrieve the entire license assignment payload in a single audit log record.

For best practices, it is advisable to continue using the correlationId and sequence metadata to reconstruct the full payload as you have described. However, for official guidance or confirmation on this behavior, I recommend reaching out to Microsoft support or checking the latest updates in the Microsoft Graph documentation, as the context does not provide specific answers to your queries regarding this issue.

References:

Share via

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

Observed Behavior

Impact

Workarounds Evaluated

Clarification Requested

2 answers

Your answer