You just got an email because someone edited a spreadsheet in a document library you follow. That small, dependable notification has been part of SharePoint for close to two decades, and Microsoft has confirmed classic alerts are being retired. If your teams lean on the little bell icon to know when a contract changes or a shared list gets a new row, that workflow needs a new home before the feature disappears from your tenant.
Why This Migration Cannot Wait Until the Retirement Date
Classic SharePoint alerts are configured per user, per list, and often per individual employee's own initiative rather than through any central admin process. That decentralisation is exactly what makes the retirement disruptive: there is no single admin console listing every alert in the tenant, no bulk export, and no way to know how many people are quietly relying on one until it stops arriving. Waiting for the retirement date to force the issue means dozens of small workflow breakages landing at once, each one reported individually to the helpdesk with no context.
Migrating proactively spreads that work out. It also produces something classic alerts never had: a documented, centrally visible replacement that an admin can audit, modify, and hand off, rather than a personal setting buried in one user's list view.
For background on the retirement itself, see the SharePoint alerts retirement announcement. Power Automate's expanded role in SharePoint workflows is covered separately in the Power Automate integrated workflow update.
How Does Power Automate Replace a Classic Alert?
A classic alert and a cloud flow accomplish the same outcome through different mechanics. An alert is a passive subscription: SharePoint watches for a matching change and emails the subscriber automatically, with no visible configuration beyond the alert dialog itself. A Power Automate flow is an explicit, editable object: a trigger fires when a matching event occurs, then one or more actions run in sequence, typically ending in an email or a Teams notification.
- The flow's trigger (for example, "When an item is created or modified") replaces the alert's event type.
- A filter condition inside the flow replaces any alert scoping, such as "only items where I am the person responsible."
- An email or Teams action replaces the alert's notification delivery, with far more control over formatting and recipients than the original alert offered.
Step 1: Inventory Every Existing Alert
Because alerts are self-service, the first job is discovery rather than migration. Ask list and library owners which lists have alerts configured against them, and for high-value lists, check directly using the list's own alert management page under list settings. Record the trigger type (item added, item changed, item deleted) and the frequency (immediate, daily digest, weekly digest) for each one found.
What to Record for Each Alert
| Field | Why it matters for the flow |
|---|---|
| List or library | Determines the SharePoint connector's site and list parameters |
| Trigger event | Maps directly to the flow's trigger type |
| Frequency | Immediate maps to a standard trigger; digests need a scheduled flow instead |
| Recipient | Becomes the "To" field on the flow's notification action |
Step 2: Map Alert Criteria to a Power Automate Trigger
Open Power Automate and start from the SharePoint connector's standard triggers: "When an item is created," "When an item is created or modified," and "When an item is deleted" cover the vast majority of classic alert scenarios. For an alert scoped to changes made by a specific person or to a specific view, add a condition action immediately after the trigger that checks the relevant field before continuing to the notification step.
Digest-style alerts need a different shape entirely. Instead of a per-event trigger, build a scheduled flow (for example, running once daily at 7am) that queries the list for items modified since the last run and compiles the results into a single summary email. This is more setup than an immediate-trigger flow, but it is a one-time cost per digest-style alert being replaced.
Step 3: Build and Test the Replacement Flow
Build the flow end to end: trigger, any filter conditions, and the notification action. Test it against real changes in the target list before telling anyone the migration is complete. Confirm the notification content includes enough context (item title, a direct link, and what changed) to be at least as useful as the original alert email, since a vague generic notification is a common reason users complain a "replacement" feels worse than what it replaced.
Read why these retirements tend to compound if this is not the first Microsoft automation feature your tenant has had to migrate off in recent years.
Step 4: Run in Parallel, Then Decommission the Old Alert
Leave the original classic alert active for one to two weeks after the flow goes live. This overlap period lets you confirm the flow behaves correctly against real-world changes without risking a silent gap in notifications if something in the flow was misconfigured. Once the flow has proven reliable, remove the classic alert, and send a short note to affected users explaining that notifications are now coming from a Power Automate flow rather than the built-in alert system, including who to contact if the new notification format needs adjusting.
For lists with a large number of individually configured personal alerts, tackle the migration list by list rather than trying to convert the entire tenant at once. A phased rollout, prioritised by business criticality, keeps the scope of each week's work manageable and gives you a track record to point to if a department pushes back on the change.
Frequently Asked Questions
Will my existing SharePoint alerts stop working immediately?
No. Classic alerts keep functioning until Microsoft's retirement reaches your tenant. Migrating ahead of that date avoids a rushed, reactive replacement effort once the feature is switched off.
Can Power Automate replicate immediate, daily, and weekly alert digests?
Immediate alerts map directly to a standard triggered flow. Daily and weekly digests require a scheduled flow that queries changes since the last run and compiles them into one notification, since Power Automate does not batch trigger events the way classic digest alerts did.
Does Power Automate cost extra on top of a Microsoft 365 licence?
Standard SharePoint, Outlook, and Teams connector usage in a typical notification flow is covered under the Power Automate for Microsoft 365 licence included with most plans. Premium connectors and dedicated per-flow plans are only relevant for more advanced automation outside basic notifications.