SharePoint Alerts Are Gone: 3 Ways to Rebuild Them

SharePoint Alerts stopped working in July 2026. Not deprecated, not expiring soon. Every alert configured across every tenant stopped delivering, and there is no way to extend them. If notifications quietly went silent a couple of months ago and nobody connected it to anything, this is why.

The part that catches people rebuilding: nothing was migrated automatically. Microsoft did not convert alerts into Rules or flows. Every single one has to be rebuilt by hand, and the obvious replacement cannot reproduce what a lot of those alerts were actually doing.

In this post: Prerequisites · What actually happened, and when · Find out what you lost first · Option 1: SharePoint Rules · The digest gap · Option 2: Power Automate · Option 3: the new digest trigger · The self-service problem nobody mentions · When would you actually use this? · Related reading

Prerequisites

Edit permission or better on the list or library to create a Rule. This is a meaningful change from Alerts, which any user with Read access could set up for themselves. More on why that matters below.
PnP PowerShell if you want to inventory what existed rather than rebuilding from user complaints.
A Power Automate licence that covers your trigger volume if you go the flow route, particularly for anything running per-item across a busy library.

What actually happened, and when

July 2025: creation of new Alerts blocked for newly onboarded tenants.
October 2025: existing Alerts began expiring on a 30-day cycle, with users able to self-service renew for another 30 days.
January 2026: creation of new Alerts blocked for existing tenants.
July 2026: full retirement. Every alert stopped firing regardless of how many times it had been renewed.

Worth being precise about what Alerts could do, because it sets up why the replacement isn’t a like-for-like swap. A classic Alert let you pick a frequency (immediately, daily summary, or weekly summary, with a chosen time and day), a change type (all changes, new items added, existing items modified, items deleted), and a filter (anything changes, someone else changes a document, someone else changes a document created by me, someone else changes a document last modified by me).

Find out what you lost first

Rebuilding from whoever complains loudest gets you the alerts belonging to your noisiest users, not the ones that mattered. Before rebuilding anything, try to enumerate what was configured. Get-PnPAlert with -AllUsers returns alerts across the current site regardless of which user or list they belonged to:

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive

Get-PnPAlert -AllUsers |
    Select-Object Title, AlertFrequency, AlertType, EventType, ListUrl, User |
    Export-Csv "C:\AlertInventory\site-alerts.csv" -NoTypeInformation

Worth setting expectations honestly here: this is a site-by-site cmdlet, and whether the alert records still return anything post-retirement depends on what remains in your tenant. Run it and see. If it comes back empty, that avenue is closed and you’re rebuilding from user reports. For a tenant-wide picture, the Microsoft 365 Assessment tool includes a SharePoint Alerts scanner that produces a Power BI report of alerts defined across the tenant, filterable by site collection and web. That’s the better starting point if you’re dealing with more than a handful of sites.

Option 1: SharePoint Rules

Rules are the no-code, built-in option, created directly from a list or library via Automate > Rules > Create a rule. The available triggers:

A column changes
A column value changes
A new item is created
An item is deleted
A date approaches

Each rule can fire always, or conditionally: “when a new file is added and Created By is not me”, for instance, which covers a chunk of what the old “someone else changes a document” filter did.

The real limits worth knowing before committing to Rules:

15 rules maximum per list or library. A hard ceiling, and lower than it sounds once several people want their own notification.
Only 2 “a date approaches” rules per list or library specifically.
Multi-line text columns aren’t supported as a rule condition.
Edit permission or better is required to create one.

SharePoint Rules cannot send a daily or weekly digest at all. If an alert was set to “daily summary”, Rules has no equivalent. That’s the single biggest gap in the like-for-like swap.

The digest gap

This is the one that derails rebuild projects. Classic Alerts offered immediate, daily summary, and weekly summary. Rules only fire immediately. There is no digest option, no batching, no “send me one email at 5pm with everything that changed.”

That matters more than it first appears, because daily and weekly summaries were exactly what people used on busy libraries specifically to avoid a flood of individual emails. Swap those to Rules and you don’t get a degraded version of the same thing. You get the flood the digest existed to prevent, and users turn the notification off within a week. Anywhere an alert was set to daily or weekly, Rules is the wrong replacement and one of the two Power Automate approaches below is the right one.

Option 2: Power Automate

The flexible option, and the one that handles anything Rules can’t: conditional logic beyond a single comparison, document-specific behaviour, sending to different people based on content, or anything touching a column type Rules won’t accept.

The relevant SharePoint triggers are When an item is created, When an item is created or modified, and When a file is created or modified. One genuine gotcha worth building around from the start: “When an item is created or modified” fires on modifications your own flow makes. If the flow updates the item it’s watching (stamping a status column, writing a “notified on” date), that update re-triggers the flow, and you have a loop. Guard it with a condition that exits when the modifying account is the flow’s own connection, or by checking whatever field the flow itself sets.

For a digest built the manual way, the pattern is a scheduled flow rather than a triggered one: run on a recurrence, query the list for items changed since the last run, and send a single email if anything came back:

Trigger:  Recurrence (e.g. daily at 17:00)

Action:   Get items
          Site:   your site
          List:   your list
          Filter Query:  Modified ge '@{addDays(utcNow(),-1)}'

Condition: length(outputs('Get_items')?['body/value']) is greater than 0
  If yes -> Send an email (V2), with the items rendered into an HTML table

Worth indexing the Modified column if the list is large, since that filter runs against it on every scheduled execution and an unindexed filter on a big list runs into the usual list view threshold problems.

Option 3: the new digest trigger

Worth knowing about before hand-building the scheduled flow above, because it does the same job with far less assembly: Power Automate has a newer SharePoint trigger called Recurring digest of updates, aimed squarely at the gap Alerts left behind. Point it at a site and a list or library, and it emails a table of what changed, with each row carrying a link, the modified date, who modified it, and who created it.

Worth being clear on its current state rather than presenting it as finished: it is still in preview, and it covers one site and one list out of the box. Two preview quirks that will otherwise look like something you did wrong:

The When to run field displays an asterisk and its dropdown throws an error. Leave the asterisk as-is rather than trying to fix it.
There’s no run button on digest flows, so you can’t test on demand. You configure it and wait for the scheduled run to confirm it works.

For a straight “daily summary of this one library” replacement, which is a large share of what the retired alerts were doing, this is less work than the scheduled-flow pattern and worth trying first. For anything needing multiple lists or per-person subscriptions, you’re back to building it yourself.

The self-service problem nobody mentions

Alerts were per-user and self-service. Anyone who could read a library could subscribe themselves, pick their own frequency, and unsubscribe later, without involving an owner and without consuming anything shared.

Neither replacement works that way, and the two facts that make this a structural problem rather than an inconvenience are the ones already listed above: Rules need Edit permission to create, and cap at 15 per list. Put those together and a library where thirty people each want their own notification simply cannot be rebuilt as Rules. You’d exhaust the cap at fifteen, and most of those people don’t have Edit rights to create one anyway. Power Automate has no such cap, but a flow is owned by whoever built it, not by the person receiving the email.

The practical consequence is that notification management shifts from the individual to whoever owns the site, permanently. Worth deciding deliberately how you’ll handle subscription requests going forward: a shared distribution list the flow emails, a small SharePoint list people add themselves to that the flow reads recipients from, or simply accepting that notifications are now owner-configured. Any of those work. Discovering the question six months in, after rebuilding forty rules one at a time, is the outcome worth avoiding.

When would you actually use this?

Someone reports they “stopped getting emails from SharePoint” and nothing was changed on the site. That’s the July 2026 retirement, not a broken permission or a mail flow issue, and it’s worth checking before troubleshooting anything else.
The old alert was set to immediate on a single list with a simple condition. A Rule rebuilds that in about a minute, and it’s the right tool.
The old alert was set to daily or weekly summary. Skip Rules entirely, since it can’t do digests. Try the Recurring digest of updates trigger first, and fall back to a scheduled flow if you need more than one list.
A busy library had many individual subscribers. Don’t rebuild one Rule per person. You’ll hit the 15-rule ceiling, and the answer is one flow with a managed recipient list instead.

Power Automate: Streamlining Workflows covers flow types and the licensing that governs how often a rebuilt notification flow can run.
Power Automate Design Flaws and Pitfalls is worth reading before rebuilding dozens of flows, particularly on request limits.
How to Avoid List Throttling in SharePoint explains indexing the Modified column, and why an unindexed filter on a large list causes the scheduled digest above to fail.

The rebuild itself is straightforward. What catches people is assuming Rules is a drop-in replacement, discovering halfway through that it can’t do digests and caps at fifteen, and having to redo the work as flows. Sort the immediate-versus-digest split first, and the rest follows.

If you found alerts still enumerable in your tenant after July, I’d be curious to know. Drop a comment. It would be useful for anyone still trying to inventory what they lost.