Title

OneNote page lastModifiedDateTime stuck at createdDateTime — affects both SharePoint-hosted and personal/OneDrive notebooks

Body

Microsoft Graph's documented contract for OnenotePage.lastModifiedDateTime says:

"The date and time when the page was last modified."

In my environment, this field stays equal to createdDateTime regardless of how the page is edited, on both SharePoint-hosted and personal/OneDrive-hosted OneNote notebooks. There's a related earlier report at https://learn.microsoft.com/en-us/answers/questions/2123280 that went stale — filing this as a fresh case with sharper repro evidence.

Endpoints affected

Both:

• GET /sites/{siteId}/onenote/pages/{pageId} — SharePoint site-hosted notebooks
• GET /users/{userId}/onenote/pages/{pageId} (and the equivalent /me/...) — personal / OneDrive-hosted notebooks

Reproduction

I edited a page's body multiple ways over a 12-day period, on both endpoint scopes, against multiple test notebooks.

Channel 1 — OneNote on the web

• Multiple body edits, saved (auto-saves)
• The body content reflects every edit when retrieved via GET /onenote/pages/{id}/content

Channel 2 — Graph PATCH /content

• PATCH /onenote/pages/{pageId}/content with body:

  ```json

  [{"target":"body","action":"append","content":"<p>test edit</p>"}]

  ```

• Returns 204 No Content
• Subsequent GET /content confirms the appended <p> is in the body

After all of those edits across both channels, fetching the page metadata:

GET https://graph.microsoft.com/v1.0/{site-or-user-scope}/onenote/pages/{pageId}

Returns (timestamps anonymized to creation time T0):

{

  "title": "...",

  "createdDateTime": "T0",

  "lastModifiedDateTime": "T0"

}

Both timestamps still equal the original creation time despite many confirmed body edits. Same pattern across every page I tested — lastModifiedDateTime == createdDateTime for all of them, including pages I have actively edited.

What does work — OnenoteSection.lastModifiedDateTime

The parent section's lastModifiedDateTime does update correctly on body edits, on both endpoint scopes:

GET https://graph.microsoft.com/v1.0/{site-or-user-scope}/onenote/sections

Before edit (T1): "lastModifiedDateTime": "T1"

After a body edit (T2, ~14 hours later): "lastModifiedDateTime": "T2"

Other sections in the same notebook (without edits) didn't bump. So the change-tracking machinery exists at section granularity, with proper isolation per section — what's missing is propagation to the page resource.

Title edits do propagate

For comparison, when I edit a page's title (not body) via OneNote on the web, the page-level lastModifiedDateTime does update within minutes. So the field isn't completely frozen — body edits specifically don't trigger it.

Impact

Any application using OnenotePage.lastModifiedDateTime for incremental sync, change detection, or "recently edited" UX will silently miss every body edit. The field appears to support the use case (it exists and updates for some operations) but is unreliable for the most common edit type — body content changes.

Ask

This is a defect that needs a fix on Microsoft's side, not a documentation clarification or a workaround:

1. Please fix OnenotePage.lastModifiedDateTime so it updates when page body content is edited. This is the canonical, documented field for "the date and time when the page was last modified." When the body changes, the field must change. The fix is on the server-side propagation path that already exists for the parent OnenoteSection.lastModifiedDateTime (which works correctly) — the same change signal needs to also bump the page-level field. Title edits already propagate; body edits should too.
2. Please open a tracking item and share the ID so we (and any other affected app) can follow the fix to release. The repro is small and deterministic (steps above), unrelated to tenant configuration (verified across both team-site and personal-OneDrive backends), and impacts any application using this field for incremental sync, change detection, or "recently edited" UX.
3. In the interim, please publicly document the current behavior at https://learn.microsoft.com/en-us/graph/api/resources/onenotepage. The current docs say the field is "the date and time when the page was last modified" with no qualifier, which is misleading — apps integrating against this field today get silent data-staleness bugs in production. A clear note saying "currently does not propagate body content edits — see KB/issue #XXX" would prevent further integrations from being built on a broken assumption while the underlying fix is in flight.