How Microsoft delivers the file-changed notifications

Purpose

This page explains how Microsoft delivers change notifications to MetaDefender Storage Security (MDSS) when Event-Based Real-Time Protection (RTP) is enabled for a SharePoint Cloud site, and what timing to expect.

It answers the most common question we receive:

A user made several edits to a document in quick succession, and each one was saved. Why did MDSS receive only one notification instead of one per edit?

Short answer: this is Microsoft's documented behaviour, not a loss of coverage. Microsoft deliberately groups changes together, and a notification is only a signal that something changed — MDSS then queries Microsoft for the full list of changes and scans the file in its current state. No change is skipped.

The remainder of this page provides the detail, with references to the official Microsoft documentation for every statement.

1. How MDSS subscribes

When you enable Event-Based RTP on a SharePoint Cloud site, MDSS creates one Microsoft Graph subscription per document library in that site.

Each subscription is created against the Microsoft Graph list resource:

This is the resource path Microsoft documents for SharePoint document libraries — see the Supported resources table in Set up notifications for changes in resource data, which lists:

list under a SharePoint site — Changes to content within the list: /sites/{site-id}/lists/{list-id}

MDSS renews each subscription automatically before it expires. Microsoft caps SharePoint list subscriptions at 42,300 minutes (just under 30 days), per the Subscription lifetime table on the same page.

2. How Microsoft delivers the notifications

Three separate Microsoft mechanisms sit between a user's edit and the notification MDSS receives. Each one groups changes together.

Layer 1 — Office for the web saves periodically, not per keystroke

When a document is edited in the browser, the "Saved" indicator means the change was committed to the Office co-authoring session. The file itself is written back to SharePoint on a timer.

From Co-author using Microsoft 365 for the web, section Word for the web co-authoring behavior:

Auto-save frequency: Every 30 seconds if document is updated. In other words, if users are actively editing a document, PutFile is called every 30 seconds. But if users stop editing for a period of time, Word for the web doesn't call PutFile until document changes are made again.

The same page's Table 1 documents all three applications:

Consequence: several edits made within the same interval result in one file write to SharePoint, not one per edit.

Layer 2 — SharePoint batches notifications and sends them once a minute

SharePoint does not notify subscribers at the moment a change occurs. From SharePoint webhooks sample reference implementation, section Grab the changes your service needs to act upon:

SharePoint does not call your service in real-time: when a change happens on a list that has a webhook, SharePoint queues a webhook callout. Once each minute, this queue is read and the appropriate service endpoints are called. This batching of requests is important. For example, if a bulk upload of 1000 records occurred at once, batching prevents SharePoint from calling your endpoint 1000 times.

And from Overview of SharePoint webhooks, section Receiving notifications:

Multiple notifications to your application may be batched together into a single request if multiple changes occurred in the resource within the same time period.

Layer 3 — The notification does not contain the changes

This is the most important point for understanding why grouping is safe. From Overview of SharePoint webhooks, section Receiving notifications:

The notification doesn't include any information about the changes that triggered it. Your application is expected to use the GetChanges API on the list to query the collection of changes from the change log and store the change token value for any subsequent calls when the application is notified.

A notification is a signal, not a payload. It identifies the document library that changed — never the file.

A notification looks like this (identifiers replaced with placeholders):

Note that resourceData contains only a type marker — there is no file name, file ID, or change detail.

3. What MDSS does when a notification arrives

1. Receives the notification and identifies which document library it refers to.

2. Calls Microsoft Graph's delta query for that library, resuming from the point the previous query finished.

3. Receives the complete list of everything that changed since then — however many changes accumulated.

4. Submits each changed file for scanning.

Because step 2 always resumes from where the previous query stopped, grouping cannot cause a change to be skipped. If Microsoft groups ten edits into one notification, the delta query returns all ten. This is the pattern Microsoft prescribes in the documentation quoted in Layer 3 above.

It also means a file is scanned in its current state rather than once per intermediate save — which is the desired outcome, since intermediate drafts are superseded before a scan of them would finish.

4. Expected timing

Published Microsoft figures for a SharePoint document library:

The 6-hour figure is Microsoft's stated maximum for the list resource and represents the worst case under service degradation. Typical delivery is under a minute.

Observed example

In a customer environment, a single document was edited continuously in the browser for roughly 13 minutes. MDSS received 9 notifications for that document library. The shortest interval between any two notifications was 36 seconds.

That matches the documented behaviour precisely: a 30-second save cadence feeding a queue drained once a minute cannot produce notifications closer together than roughly half a minute, regardless of how many keystrokes occur.

5. Frequently asked questions

A user saved five times in five seconds but MDSS received one notification. Was anything missed? No. Five saves within five seconds produce approximately one file write to SharePoint (Layer 1), and any changes within the same batching window are grouped into one notification (Layer 2). The delta query returns the file in its latest state, so it is scanned.

Can MDSS receive a notification per individual edit? No. This is controlled entirely by Microsoft and is not configurable. The notification carries no file-level information, so a per-edit notification would contain nothing to distinguish it.

What happens if hundreds of files change at once — for example a bulk upload? Microsoft sends a small number of notifications rather than one per file, exactly as described in the 1,000-record example quoted in Layer 2. The delta query returns all the changed files, and MDSS scans each one.

What is the maximum delay before a new or modified file is scanned? Under normal conditions, typically under a minute plus scan time. Microsoft's documented maximum notification latency for a SharePoint list is 6 hours — see the Latency table.

Does anything need to be configured to make notifications arrive faster? No. The intervals are Microsoft service behaviour and cannot be changed by MDSS or by tenant configuration.

Is Event-Based RTP the right choice for files edited continuously in the browser? Yes. Event-Based RTP scans the file as it reaches its saved state in SharePoint. For workloads where you want a guaranteed sweep independent of notification delivery, combine it with a scheduled on-demand scan.

6. Microsoft reference documentation