Modern SharePoint Online and Microsoft Lists introduced an experience where list items behave more like “collaboration objects” than just rows in a table. One of the clearest examples is Comments in modern list item forms.

SharePoint Online (Modern) List Item Comments: How They Work, How They’re Stored, and How to Automate Notifications

Modern SharePoint Online and Microsoft Lists introduced an experience where list items behave more like “collaboration objects” than just rows in a table. One of the clearest examples is Comments in modern list item forms.

At first glance, Comments look like a standard “column” or a field on the form. In reality, they are not a classic list column like Title, Choice, Person, or Date columns. Comments are a separate comment thread attached to the list item, surfaced by the modern UI.

This article explains what that means technically, how comments differ from fields, how you access them via APIs, and what this implies for Power Automate—especially if your goal is to notify people whenever someone adds a new comment.

1) What Comments Are (and What They Are Not)

Comments are a thread, not a field

In modern SharePoint lists, each list item can have a comment thread. Users can add comments, reply, and use @mentions (and SharePoint can notify mentioned users). Microsoft’s user documentation describes the comments experience as part of working with list items rather than defining it as a list column.

A normal list column:

• is stored in the item’s field values
• is returned by typical list item reads (fields)
• is filterable/sortable in views
• is easy for workflows to detect as “changed”

A comment thread:

• behaves like an attached conversation
• is not included as a normal “field value” in the list item’s fields payload
• is retrieved via comment-specific endpoints rather than field reads

2) How the Modern Form Uses Comments

When you open a list item in the modern UI, the experience usually involves two conceptual “loads”:

1. Fields: SharePoint loads the item’s structured fields (Title, Status, Owner, etc.)
2. Comments thread: SharePoint loads the comment feed associated with the item

When users add a comment, SharePoint appends it to the thread and can send notifications on @mentions.

Practical result: Comments behave more like “activity” than “data fields.”

3) Where Comments Live Conceptually

A helpful mental model:

• List item fields = structured data (“columns”)
• List item comments = conversation stream (author, timestamp, body, mentions, replies)

This matters because most tools—including Power Automate—are optimized for field changes, not conversation events.

4) Why Power Automate Doesn’t “Just Trigger on Comment Added”

Power Automate has strong SharePoint triggers like:

• “When an item is created”
• “When an item is created or modified”
• “When an item is modified”
  and actions like:
• “Get changes for an item or file (properties only)”

However, Microsoft’s SharePoint connector “Get changes…” is explicitly about columns/properties changed in a time window. It’s designed for detecting field changes, not comment thread events. (Microsoft Learn)

That’s the root limitation you’ll see repeated across community guidance:

• There isn’t a native, first-class trigger that reliably fires only when a comment is added to the built-in comments thread.
• So your workflow design must treat comment detection as a separate problem.

This is why real-world solutions typically use SharePoint REST via “Send an HTTP request to SharePoint” when built-in connector actions aren’t enough. Microsoft explicitly recommends that action when a capability “is not yet available in the SharePoint connector.” (Microsoft Learn)

5) The Key Tool: “Send an HTTP Request to SharePoint” (REST)

Microsoft Learn provides official guidance for the Send an HTTP Request to SharePoint action in Power Automate, specifically positioning it as the escape hatch when the standard connector doesn’t meet the requirement. (Microsoft Learn)

And Microsoft Learn’s SharePoint REST documentation covers how list items are accessed and manipulated via REST. (Microsoft Learn)

Together, those two pieces form the foundation of comment automation:

• You trigger a flow (somehow)
• You call REST to read items(ID)/comments
• You compare with previous state
• You notify

6) Retrieving Comments via REST: the /comments Pattern

A widely referenced approach is retrieving comments using an endpoint shaped like:

.../_api/web/lists/getbytitle('Example List')/items(123)/comments

Community answers and technical references consistently point to comments existing under the Items() endpoint as Comments() rather than as a file endpoint. (Stack Overflow)

This matches the architectural idea:

• comments are “attached” to the list item object
• they are not a normal field you expand under item fields

7) Adding Comments via REST (Optional, but Useful)

You can also add a comment programmatically (for example, to log workflow actions) using REST and the same Power Automate HTTP action pattern. Many implementations follow the principle:

• HTTP POST to the comments endpoint
• JSON body with the comment text
• correct headers

The important takeaway for a solution designer is that you can both read and write comments using REST, even though the connector doesn’t give a dedicated “comment action.” (Microsoft Learn)

8) Admin Control: Comments Can Be Disabled for a List

Microsoft’s user documentation notes that if comments aren’t visible, it can be due to admin settings (comments disabled for the list).

This matters for automation because:

• If comments are disabled, your flow might be irrelevant
• Or your flow might fail because the endpoint returns empty/unexpected results
• You should validate comments are enabled in the list you’re automating

9) Permissions and Governance Considerations

Comments inherit the collaboration and permission model of the list item experience:

• Users typically need more than “read-only” to participate in commenting
• Item-level permissions can restrict who can read or add comments
• If you plan notifications, you must ensure you’re not disclosing comment content to users who shouldn’t see it

Community guidance also highlights permission nuances (e.g., visitors vs editors). (TECHCOMMUNITY.MICROSOFT.COM)

10) What This Means for Notification Automation

Because there is no “perfect” native trigger for “comment added”, most real implementations fall into these patterns:

Pattern A — Polling: Scheduled flow checks for new comments

• Trigger: Recurrence (every X minutes)
• For each target item (or subset), call REST /comments
• Compare last known comment ID/time
• Send notifications only for new comments

Pros: Reliable, controlled, doesn’t depend on item modification behavior
Cons: Requires state tracking; can be heavy if the list is large

Pattern B — Item modified trigger + REST validation

• Trigger: When an item is created or modified
• Then: call /comments
• Determine if a new comment exists since last run
• Notify

Pros: More event-like, fewer scheduled scans
Cons: Not guaranteed that a comment always produces an item modification event in a way you can cleanly filter; still needs state logic

Pattern C — Custom comment UX

• Replace the built-in comments UX with a custom UI (SPFx/Power Apps)
• That custom UI calls automation directly (webhook/Azure Function/flow)
• Notify immediately with full control

Pros: Best governance and reliability
Cons: More engineering effort and change management

Microsoft’s own Power Automate guidance for the SharePoint HTTP action supports these approaches, because it exists exactly for “connector doesn’t do what you need.” (Microsoft Learn)

11) Recommended Architecture for Most Teams (Pragmatic)

For most SharePoint teams that want notifications without building custom UI:

1. Use a scheduled flow (Pattern A) to avoid unreliable “comment triggers”
2. Use Send an HTTP request to SharePoint to read /comments
3. Track the last-notified comment (per item) in either:
   • a helper list (recommended)
   • or a single “state” column on the same item (if acceptable)
4. Notify:
   • item creator
   • assigned person
   • watchers list
   • @mentioned users (optional, because SharePoint may already do this)

This becomes predictable, auditable, and easy to maintain.

Summary Tables

A) How Comments Work (Conceptual)

B) Power Automate Building Blocks