There is no first-class SharePoint connector trigger that reliably fires “when a comment is added” for modern list item comments, so the stable pattern is: run on a schedule, query comments via REST, compare state, notify only for new ones. (Microsoft Learn)

Scheduled flow that detects new comments and sends notifications

Why this is the best baseline

There is no first-class SharePoint connector trigger that reliably fires “when a comment is added” for modern list item comments, so the stable pattern is: run on a schedule, query comments via REST, compare state, notify only for new ones. (Microsoft Learn)

Architecture

Inputs

• A target list: “Example List” in https://contoso.sharepoint.com/sites/ExampleSite
• A polling interval: e.g., every 5 minutes
• A rule for who gets notified:
  • Item Created By
  • Assigned To / Owner
  • A “Watchers” people column (optional)
  • Or a fixed mailbox / Teams channel

State tracking (mandatory to prevent duplicates)

You must store what you already notified.

Best practice: create a helper list (e.g., “Comment Notification State”) with:

This makes the flow predictable and avoids writing “state” into business data.

Step-by-step Power Automate build (Workflow A)

1) Trigger: Recurrence

• Every 5 minutes (or 10/15 depending on volume)

2) Action: Get items (from “Example List”)

• Use OData filters to limit the scan:
  • Example: only items in an “Active” status
  • Or only items modified in last X days
• This reduces REST calls.

Tip: even if comments don’t always update “Modified” the way you expect, limiting to “active items” is still valuable.

3) For each item → call SharePoint REST to get comments

Action: Send an HTTP request to SharePoint

Microsoft Learn explicitly recommends this action when the standard connector doesn’t cover what you need. (Microsoft Learn)

• Site Address: https://contoso.sharepoint.com/sites/ExampleSite
• Method: GET
• Uri (important: many examples use lowercase comments):_api/web/lists/getbytitle('Example List')/items(@{items('Apply_to_each')?['ID']})/comments

This “comments under items()” pattern is consistent with how the Comments endpoint is exposed. (Stack Overflow)

• Headers:
  • Accept: application/json;odata=nometadata

4) Parse the response so you can compare it

Action: Parse JSON

• Content:body('Send_an_HTTP_request_to_SharePoint')

Schema (practical minimal)
(You can generate it automatically by using a sample output from a run.)

You typically want:

• comment id
• comment text
• createdDate
• author info (name/email)

5) Load the last processed state for this item

Action: Get items (from “Comment Notification State”)

• Filter Query:Title eq 'Example List|@{items('Apply_to_each')?['ID']}'

If no record exists → treat as first run for that item:

• create a state record with the latest comment id/time (and do not notify), OR
• notify only for the most recent comment (your choice)

6) Determine what’s “new”

Strategy (simple and reliable)

1. Identify the latest comment returned by the endpoint.
2. Compare its id (or createdDate) with LastCommentId/LastCommentTime.
3. If it’s newer → notify and update state.

Why id is ideal:

• monotonic within the thread, simpler than time parsing
• prevents “same timestamp” collisions

Pseudo-logic

• latestId = max(comments[].id)
• If latestId > LastCommentId → new comment exists

Note: Some endpoints may return comments in chronological order; don’t assume ordering—take max id to be safe.

7) Build the notification payload

Notification options

• Send an email (V2)
• Post a message in a chat or channel (Teams)
• Adaptive Card (more advanced)

Email content recommendation
Include:

• List name
• Item title
• Item link (deep link)
• Comment author and timestamp
• Comment text (trim if needed)
• A “View item” link

8) Update state after successful notification

Action: Update item (in “Comment Notification State”)

Set:

• LastCommentId = latestId
• LastCommentTime = latestCreatedDate
• LastRun = utcNow()

Handling multiple new comments since last run

If you want to notify for every new comment since the last checkpoint:

1. Filter the comments array:
   • comment.id > LastCommentId
2. Sort ascending by id
3. Loop and send one notification per comment (or aggregate into one email)

This is the “enterprise” version (more accurate, more actions).

Performance + limits you must design for

A) Volume

If your list has thousands of items, do not scan them all every 5 minutes.
Use:

• Active status filter
• Date range filter
• Or a “Watch” flag column (only items where notifications matter)

B) Pagination/top limits on comments

Some APIs can return partial sets (for large threads). If you expect items with hundreds of comments, test and consider paging patterns. Community threads show “top 200” style behavior in some contexts, so don’t assume infinite results. (SharePoint Stack Exchange)

C) Permissions

The connection account running the flow must:

• read items
• read comments
• read people fields if you notify assigned users

Workflow B (Hybrid): Trigger on item modified, then validate via /comments

This is useful if you want fewer scheduled scans.

Steps

1. Trigger: When an item is created or modified
2. Call REST: .../items(ID)/comments
3. Compare latest comment id/time with stored state
4. If new → notify → update state

Risk: depending on tenant behavior, a comment may not always produce the kind of “modified” signal you can cleanly depend on. That’s why the scheduled version is the safest baseline. (Microsoft Power Platform Community)

Exact REST endpoint pattern to remember (blog-safe)

• Comments are accessed under items(), not like normal fields. (Stack Overflow)
• Use Power Automate’s HTTP action when SharePoint connector actions aren’t enough. (Microsoft Learn)
• Standard list/item REST guidance is documented on Microsoft Learn. (Microsoft Learn)

Summary tables

Build steps (Workflow A)

Technical decisions