Best approach to track add/update/rename/move changes across multiple folders at document library root — Graph delta vs GetChanges?

Husain Saify 0 Reputation points
2026-08-29T09:58:12.15+00:00

We're building a service that needs to detect file/folder-level changes

(create, update, rename, move) across an entire SharePoint document

library root, which contains multiple subfolders — not just a single

flat folder. Delete/remove tracking is not required.

Current setup:

  • A Microsoft Graph webhook subscription on /drives/{drive-id}/root to get notified when something changes.
  • A Graph delta query (/drives/{drive-id}/root/delta) with a stored deltaLink to fetch the actual changed items incrementally.

This works, but Graph delta doesn't return an explicit change type

(rename vs move vs content update) — we infer it ourselves by comparing

item id, name, and parentReference.path against a locally stored state.

We evaluated the classic SharePoint REST GetChanges API

(_api/site/GetChanges, _api/web/lists/GetByTitle('...')/GetChanges) as

an alternative, since it returns an explicit ChangeType (Add/Update/

Rename/MoveAway/MoveInto). However, we found a few concerns that make

us hesitant to rely on it.

  1. It requires Sites.FullControl.All (or the classic FullControl app-only scope) — a much broader permission grant than Graph delta needs (Sites.Read.All / Files.ReadWrite.All).
  2. We've seen reports, and reproduced it ourselves, that GetChanges at folder scope does not reliably return Move events.
  3. It uses a separate SharePoint-scoped auth token/resource, distinct from our existing Graph app registration and token flow.

Questions:

  1. For root-level, multi-folder change tracking (create/update/rename/ move only), is Graph delta still the recommended approach, even though it requires us to infer rename/move ourselves? Or is there a supported way to get more explicit change-type info without the FullControl requirement?
  2. Is there a recommended pattern for scoping delta queries when the root contains multiple subfolders, or is /root/delta already the correct entry point for the whole tree (as opposed to calling delta separately per subfolder)?
  3. Is the GetChanges Move-detection gap we've seen at folder scope a known/expected limitation, or are we querying it incorrectly (e.g., wrong ChangeQuery flags, or the wrong scope object)?
  4. Is there any other current, supported Graph or SharePoint API worth considering for this — something newer than delta or GetChanges — for production-grade file-level change tracking across a multi-folder library?

Environment: SharePoint Online, Microsoft Graph v1.0, .NET/C# backend,

Azure AD app registration with application permissions.

Microsoft 365 and Office | SharePoint | Development
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jade Ng 15,310 Reputation points Microsoft External Staff Moderator
    2026-08-29T11:04:57.8033333+00:00

    Dear Husain Saify,

    Thank you for your detailed question and for outlining the approaches you've already evaluated.

    Based on the current Microsoft Graph and SharePoint capabilities, for a solution that needs to track file and folder changes across an entire SharePoint document library hierarchy, the recommended approach is typically to use Microsoft Graph change notifications (webhooks) together with DriveItem delta queries. The driveItem/delta API is designed for incremental synchronization and tracking changes across a drive and its descendants over time. It supports tracking changes throughout the library when called at the library root (/drives/{drive-id}/root/delta).

    Regarding your specific questions:

    1.Root-level tracking across multiple folders: Calling /root/delta is generally the correct entry point for tracking changes across the entire document library tree. The delta API enumerates the hierarchy and returns changes for items throughout the drive rather than requiring separate delta queries per subfolder.

    User's image

    2.Rename and move detection: The delta API returns the current state of changed items rather than an explicit operation type. As a result, applications commonly determine rename or move events by comparing stable item IDs along with properties such as the item name and parent location between synchronization cycles.

    3.GetChanges behavior: I was unable to find Microsoft documentation that explicitly states MoveAway/MoveInto events are unsupported or unreliable at folder scope. However, it also does not appear to guarantee that move operations will always be surfaced as MoveAway and MoveInto events across all query scopes. Based on those observations, I recommend validating the behavior against your specific scope and workload before relying on those event types for synchronization logic.

    4.Alternative APIs: At this time, there is no newer Microsoft Graph API that provides explicit move/rename operation types for DriveItems while offering the same modern Graph-based synchronization model. The combination of Graph webhooks and delta queries remains the primary supported pattern for production-grade file change tracking.

    Based on your requirements and the permission considerations you've raised, continuing with the Graph webhook + root delta approach and inferring move/rename operations from item metadata changes would generally be the most future-proof and least-privileged design.

    For more reference:

    Additionally, to obtain more detailed guidance on this matter, I recommend engaging Microsoft Graph Engineering Support. They are best positioned to provide authoritative clarification regarding the expected behavior of the relevant APIs and any service-specific considerations that may not be fully covered in the public documentation.

    You can contact them via:

    The support team over there has higher permission than us to investigate the issue from background, they have more resource and correct escalation channel in handling this kind of issues. This would be a more efficient way in handling the case for you.  

    I hope this helps. Please feel free to reply below if you have any update or further concern.  

    Your understanding and co-operation are highly appreciated. Thanks for your precious time. Have a nice day!

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.