SharePoint Online Modern List Item Comments: How They Work (and Why They’re Not “Just a Column”)

This article explains how Comments behave in SharePoint Online / Microsoft Lists modern forms, how they differ from normal list columns, and what this means for integrations (Power Automate, SPFx, REST, Microsoft Graph). It uses official Microsoft documentation as the primary reference and adds practical guidance you can apply in real solutions.

1) What “Comments” Really Are in Modern SharePoint Lists

In modern SharePoint Online (and Microsoft Lists), Comments are not stored as a normal field/column value the way Title, Status, or DueDate are stored.

Instead, each list item has an associated comment thread (a conversation) that SharePoint displays in the modern form experience.

From the end-user perspective, it looks like a “Comments area” on the item form:

• Users can add, reply, and sometimes delete comments (depending on permissions).
• Users can @mention others.
• The list view can show an icon indicating that an item has comments. (Microsoft Support)

Microsoft’s user-facing documentation describes this as a collaboration layer around list items, not as a classic list column. (Microsoft Support)

2) Why Comments Don’t Behave Like Columns

Columns (structured data)

A standard SharePoint column:

• lives inside the item’s field values
• participates in normal list behaviors like:
  • view filtering/sorting
  • column formatting
  • “Get changes for an item” logic in Power Automate (for the fields)

Comments (collaboration thread)

Comments behave differently:

• They are not part of the item field set you read/write as “columns”
• They are usually accessed through special endpoints (SharePoint REST comment endpoints)
• They have a conversation timeline (each comment has an author, time, body, etc.)

This distinction becomes obvious when you use APIs:

• With Microsoft Graph list items, you typically expand/select fields, but there is no “Comments column value” in that fields payload. (Microsoft Learn)
• With SharePoint REST, Microsoft documents how list items are manipulated as entities (CRUD), and comments are typically handled through separate comment-specific endpoints rather than standard field updates. (Microsoft Learn)

3) What You See in the Modern Form

When you open a list item in the modern UI:

1. SharePoint loads the item fields (Title, Choice columns, Lookups, etc.)
2. SharePoint also loads the comment thread for that item (as a separate “feature surface”)
3. When someone adds a comment:
   • it’s appended to the thread
   • the item can show a “has comments” indicator in the list UI
4. If a user uses @mention, SharePoint can notify that person. (Microsoft Support)

Microsoft explicitly notes:

• You can add/reply/delete comments
• @mentions can tag someone
• If you don’t see comments, an admin may have disabled them (Microsoft Support)

4) Data Model: A Simple Mental Picture

Think of a list item like this:

List Item (ID = 123)
├─ Fields (structured columns)
│  ├─ Title = "Project A"
│  ├─ Status = "In Progress"
│  └─ DueDate = 2026-03-01
└─ Comments Thread (unstructured conversation)
   ├─ Comment #1 (Author, Timestamp, Text)
   ├─ Comment #2 (Reply, Mention, etc.)
   └─ Comment #3 ...

This is why you can’t treat “Comments” as “just another column” for reporting, filters, or field-level triggers.

5) API Access: Graph vs SharePoint REST

5.1 Microsoft Graph: Great for list items and fields (structured data)

Microsoft Graph provides strong support for reading list items and their fields (columns), including query/filter patterns. (Microsoft Learn)

Example (generic pattern) to list items + fields:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items?$expand=fields

Graph is ideal for:

• reading/writing item fields
• filtering on indexed fields and known columns (with typical limits/constraints) (Microsoft Learn)

But: Comments are not commonly treated as part of fields in Graph list item results. In practice, you should assume comments require a different approach than normal column reads/writes. (Microsoft Learn)

5.2 SharePoint REST: The classic way to manipulate SharePoint list items (and related capabilities)

Microsoft Learn’s SharePoint REST guidance documents how to do CRUD operations on lists and items. (Microsoft Learn)

Example (generic pattern) to read a list item:

GET https://contoso.sharepoint.com/sites/ExampleSite/_api/web/lists/getbytitle('Example List')/items(123)

Microsoft Learn also explains important REST behaviors that matter in automation (ETags, concurrency control, etc.). (Microsoft Learn)

5.3 Retrieving comments via REST: the “/comments” pattern

A commonly used REST pattern to retrieve comments attached to a list item is:

GET https://contoso.sharepoint.com/sites/ExampleSite/_api/web/lists/getbytitle('Example List')/items(123)/comments

Microsoft’s community Q&A for SharePoint indicates this REST pattern for comments on list-backed content (example given for “Site Pages” list items, but the important part is the items(id)/comments approach). (Microsoft Learn)

Practical takeaway: For comments, you should think “comments endpoint” rather than “fields payload.”

6) Enabling/Disabling Comments at the List Level

End users may not see comments if:

• the list feature is disabled by an admin/owner
• the experience is not modern (classic UI differences)

Microsoft’s support note explicitly mentions the “disabled by admin” scenario. (Microsoft Support)

In the SharePoint UI, this is typically controlled via list settings/advanced settings (community guidance commonly references a “Comments” setting under advanced settings). (TECHCOMMUNITY.MICROSOFT.COM)

7) Security and Permissions: Why Comments Can Be Tricky

Conceptually:

• Reading/writing item fields depends on list permissions (Read/Contribute/Edit)
• Adding comments generally requires permissions that allow interaction with the item (commonly aligned with edit/contribute capabilities)

In real implementations, you should validate:

• Who can add comments?
• Who can read comments?
• Whether item-level permissions are used (unique permissions per item)

This becomes especially important when you want notifications (Power Automate) because “who can see what” changes how you design your workflow.

8) Implications for Power Automate (Preview of What We’ll Build Next)

Because comments are not a standard column:

• The usual SharePoint triggers like “When an item is created or modified” might not reliably represent comment actions as “field changes.”
• You often need a pattern that:
  • detects comment events (or polls/queries the comments endpoint)
  • compares the last known comment state
  • emits notifications (email/Teams/etc.)

We’ll use the concepts in this article as the foundation for a Power Automate workflow design that is robust and explicit.

9) Recommended Architecture Patterns (High-level)

Pattern A — “Native notifications” (fastest, least control)

Use built-in @mentions and SharePoint notifications behavior.
Pros: no workflow, minimal maintenance.
Cons: limited routing rules, limited custom formatting, limited audit control. (Microsoft Support)

Pattern B — “Workflow-driven notifications” (Power Automate)

Use a flow to detect comment activity and send notifications:

• email
• Teams message
• adaptive card
• audit logging

Pros: full control, extensible.
Cons: must handle comment detection carefully (because it’s not a normal field).

Pattern C — “Custom event pipeline” (SPFx/Azure Function)

When you own the UX or need enterprise-grade auditing:

• custom form/components capture comment entry
• backend persists comment + signals workflow

Pros: best control and observability.
Cons: more engineering effort.

Summary tables

Steps: how modern Comments work

Technical view: which API fits which job