Send SharePoint News Notifications with Power Automate—Without Duplicates

A flow that emails people whenever a file changes in Site Pages will eventually spam them. A SharePoint news post is a page, and publishing is not the last time that page will be modified.

The safe pattern is to separate two facts:

1. Is this page a published news post?
2. Has this notification already been sent?

This guide uses a visible NotificationSent column, a trigger condition, a second in-flow check and serialised runs. It also starts with a more important question: whether SharePoint's native news distribution already solves the problem.

Fact-checked against Microsoft Learn and Microsoft Support on 7 August 2026.

First: do you need Power Automate?

SharePoint already distributes news through the SharePoint start page, sites, hub sites, the mobile app and Viva Connections. Microsoft also provides:

• manual email news digests;
• automatic branded news digests for relevant unread posts;
• organisation news sites and authoritative news;
• news boosting; and
• audience targeting.

Use those native features when the requirement is “help employees discover relevant news”. They preserve SharePoint's permission model and avoid sending one email for every publication.

Build a custom flow when the requirement is genuinely custom—for example:

• notify a controlled mailbox or small operational group immediately;
• route different news categories to different recipients;
• post a tailored message into a specific Teams destination;
• record delivery in another system; or
• combine publication with an approval or business process.

Do not recreate a generic news digest one message at a time. Microsoft already has a digest for that.

SharePoint Alerts are no longer the answer

Starting in July 2026, Microsoft removes SharePoint Alerts from SharePoint in Microsoft 365 and recommends Rules or Power Automate for notifications.

Rules are the simpler choice when a supported list/library condition and email notification are enough. Microsoft documents rules for events such as an item being modified or a column changing.

Power Automate earns its extra complexity when you need richer conditions, destinations or delivery tracking.

The design

We will add two columns to the Site Pages library:

Column	Type	Purpose
NotificationSent	Yes/No, default No	Stops a published post being announced again after later edits
NotificationSentAt	Date and time, optional	Gives support teams visible evidence of when the flag was set

The flow will:

1. Trigger when page properties are created or modified.
2. Start only when the page is promoted as news and NotificationSent is not Yes.
3. Read the current page properties again.
4. Stop if another run has already marked the page.
5. Send the notification.
6. Update NotificationSent and NotificationSentAt only after the send succeeds.

This is an at-most-once business design under normal conditions, not a mathematical delivery guarantee. Outlook, Teams, SharePoint and the flow service can fail at different points. The test section covers that boundary.

1. Add the delivery columns to Site Pages

Open the site's Site Pages library. If it is hidden from normal navigation, use Site contents > Site Pages.

Create a Yes/No column called NotificationSent and set the default to No. Optionally create a date-and-time column called NotificationSentAt.

Use an exact, stable name. SharePoint has an internal column name as well as a display name; renaming the display label later does not necessarily change the internal name used in trigger expressions.

Create a test news post after the columns exist and confirm both fields appear in the library's item properties. Keep the test in a non-production site while building the flow.

2. Create the trigger

In Power Automate, create an automated cloud flow with SharePoint's When a file is created or modified (properties only) trigger.

Select:

• the SharePoint site; and
• the Site Pages library.

This trigger runs for page-property changes; it does not download the page file content. That is enough for a notification that uses metadata such as title, author and link.

3. Identify a published news post

SharePoint pages expose a promotion state. The Microsoft 365 PnP Core SDK documents these values:

• 0 — regular page;
• 1 — promote on publish; and
• 2 — promoted news page.

Use 2 as the news-post check, but verify the exact field path in a real trigger run from your tenant. PnP documents the model; your Power Automate trigger's dynamic-content label and raw JSON path are the implementation evidence you need.

Create and publish one test news post, open the flow's trigger output, and locate PromotedState. Do not copy an expression from the internet until you have seen the field in your own run.

4. Add a trigger condition

Open the trigger's Settings and add a trigger condition that checks both publication and delivery state.

If your run history shows the internal names exactly as PromotedState and NotificationSent, the pattern is:

@and(
  equals(triggerOutputs()?['body/PromotedState'], 2),
  not(equals(triggerOutputs()?['body/NotificationSent'], true))
)

Enter it as one line in the trigger-condition box. Substitute the actual property names from your trigger output.

The not(equals(..., true)) form intentionally treats No and an empty legacy value as “not sent”. If you need empty values handled differently, migrate the existing pages first and use an explicit Boolean check.

A trigger condition prevents obvious non-news edits and already-marked items from starting full flow runs. It does not remove the need for the second check below.

5. Serialise runs for this flow

Open the trigger settings and enable Concurrency control with a degree of parallelism of 1.

Why? Two rapid modifications can both occur while NotificationSent is still No. Serialising the flow, then re-reading the item, lets the second run see the marker set by the first.

Microsoft documents important restrictions around trigger concurrency settings. Record the original setting before changing a production flow and make this decision during design, not as a casual live tweak.

This setting reduces throughput. A news-notification flow should not normally need high parallelism, but test it against the publication rate of your estate.

6. Re-read and re-check the page

Add Get file properties or the equivalent SharePoint action that retrieves the current Site Pages item by its identifier.

Then add a Condition:

• If NotificationSent is equal to Yes, terminate the flow as successful with a clear message such as Notification already recorded.
• If NotificationSent is not Yes, continue to the send action.

This second read closes the common queued-run gap. It also makes run history easier to understand than relying on the trigger snapshot alone.

7. Build the notification

Keep the message useful and permission-safe. A simple email can include:

• the news title;
• a one-sentence description if the author supplied one;
• the author or owning team;
• the published link; and
• why this recipient is receiving it.

Do not copy the full page into email. The SharePoint link keeps the news in its governed location, and SharePoint checks the reader's access when they open it.

If sending to Teams, choose the destination deliberately and test external/guest visibility. A Teams post can expose a headline to a broader audience even when the SharePoint page itself remains protected.

Send to a test recipient first. Check the link as a normal reader, not as the flow owner.

8. Mark the notification only after success

After the send action, add Update file properties for the same Site Pages item:

• set NotificationSent to Yes; and
• set NotificationSentAt to the current UTC time, if you created that column.

Configure this update to run only after the send action succeeds. Do not set the marker before sending, or a failed delivery attempt could look complete.

Updating the marker changes the page properties and can fire the SharePoint trigger again. The new run is rejected by the trigger condition because NotificationSent is now Yes. That is expected behaviour, not an infinite loop.

What should happen when a news post is republished?

Decide this explicitly. There are two reasonable policies:

Notify once per news item

Leave NotificationSent as Yes for the lifetime of the page. Corrections and later edits do not create another notification. This is the safest default.

Notify again for a deliberate major update

Make resetting NotificationSent to No a controlled editorial action. Require the editor to confirm the audience and reason for another send.

For a stricter system, use a separate delivery log keyed by page ID and published version rather than one Boolean. That supports an auditable “once per approved version” rule but is a larger solution.

Do not automatically reset the flag on every edit. That recreates the spam problem under a different name.

Test matrix

Run all of these before enabling real recipients:

Test	Expected result
Save a draft page	No notification
Publish a normal page that is not news	No notification
Publish a news post	One notification, then marker set
Edit the published news post	No second notification
Change an unrelated page property	No second notification
Make two rapid modifications before the first run finishes	One send; queued run exits after re-check
Force the send action to fail	Marker remains No so support can retry safely
Open the delivered link as a normal recipient	Recipient sees only content they are permitted to access
Reset the marker under the approved republish process	Exactly one new notification

Also check the flow's run-only connections, owner account, failure alerts and data-loss-prevention policy. A correct expression is not an operating model.

Common failures

Every edit sends another message

The flow is checking only PromotedState. A news page remains news after publication. Add and honour the delivery marker.

Drafts trigger the flow

Inspect the raw trigger data for a draft and a published news post. Confirm the promotion-state path and whether page approval changes the sequence in your site.

Two messages arrive for one post

Check trigger concurrency, the second Get/re-check step and whether more than one flow or SharePoint rule watches the library. Search the run history by page ID.

The flow loops after Update file properties

Confirm the update actually sets NotificationSent to a Boolean Yes and that the trigger condition uses the field's internal name. Microsoft explicitly warns that self-updating flows can loop without a trigger guard.

People receive a link they cannot open

The flow can send a URL; it does not grant SharePoint access. Fix the audience or permissions rather than broadening the site by default.

Related Power Automate patterns

If you need to reuse part of this flow, follow the current copy and paste Power Automate actions guide. If your next flow is launched by a person from a list item, our SharePoint list-button guide covers that separate pattern.

Build flows people can support

The Power Automate Builders Space focuses on maintainable automation, including the failure and ownership questions that simple demos leave out.

Sources used

• Distribute corporate news to your organisation
• SharePoint news help
• Automatic branded news digests
• Create a rule for a list or library
• SharePoint Alerts retirement guidance
• PnP Core PromotedState enum
• Avoid self-triggering Power Automate flows
• Optimise Power Automate triggers

Source boundary: Microsoft documents SharePoint news, rules, Alerts retirement and flow safeguards. The NotificationSent pattern is a supportable design derived from those behaviours; it is not a Microsoft delivery guarantee. Validate field names, approval sequence, recipient access and failure recovery in your tenant.