SharePoint Online Alerts Retire July 2026: Scan and Replace Them

SharePoint Online Alerts are now inside Microsoft’s July 2026 retirement window, and administrators should treat every remaining alert as a broken dependency rather than a notification they can rescue. As of July 18, existing alerts can no longer be extended and are not expected to work, so the immediate job is to find the business processes that quietly depended on them before missed emails become help-desk tickets.
Microsoft’s SharePoint Alerts retirement notice sets the chronology plainly: creation of new alerts was disabled across all tenants beginning in January 2026, while July 2026 removes the ability to use or extend existing alerts. Microsoft recommends SharePoint Rules or Power Automate as replacements, but choosing a replacement is only one part of the response. IT also needs an inventory, a business-impact review, migration testing, and a recognizable support script for users reporting that “SharePoint stopped emailing me.”

Run the Tenant Scan Before Troubleshooting Individuals​

The most useful first move is not waiting for users to identify their own alerts. Microsoft specifically recommends running the Microsoft 365 Assessment tool to scan the tenant for SharePoint Alerts usage and begin migration planning.
Administrators should turn that recommendation into a short incident-prevention sequence:

1. Run the Microsoft 365 Assessment tool against the SharePoint Online tenant and include the scanner for SharePoint Alerts usage.
2. Generate the Power BI Alerts Report provided by the assessment process.
3. Review the reported alerts by site collection and web rather than treating the tenant as one undifferentiated list.
4. Match the affected sites, lists, and libraries to site owners and business functions.
5. Ask owners which notifications trigger operational action, approvals, document reviews, compliance work, or customer-facing activity.
6. Assign each required notification to SharePoint Rules, Power Automate, or another documented process.
7. Test the replacement with a controlled list item or file change and confirm that the intended recipient receives the expected notification.
8. Record an owner for the replacement and a support route for failures.

The scan identifies technical usage, but it cannot determine which alert matters most. An alert watching a lightly used team library and an alert watching an operational queue may look similar in inventory data while carrying very different consequences.
That is why administrators should prioritize by business dependency, not simply alert count. Start with SharePoint sites connected to time-sensitive work, then move to departmental libraries and personal convenience notifications.

---

The Dangerous Alerts Are the Ones Nobody Documented​

SharePoint Alerts were often configured directly by users on a list, library, folder, file, or item. That self-service convenience also made them easy to exclude from formal workflow diagrams, application inventories, and change-management records.
A site owner may know that an alert exists without knowing who still relies on it. Conversely, a user may depend on an email without recognizing that SharePoint Alerts generated it. The first visible symptom may therefore be a missed review, an unanswered request, or a complaint that a familiar message stopped arriving.
Microsoft says users have been shown retirement banners in relevant SharePoint Online pages and alert emails. Those warnings reduce surprise, but they do not prove that recipients understood the operational consequence or migrated the notification.
Admin outreach should use concrete language. Instead of announcing that a legacy Microsoft 365 capability has been deprecated, tell users that emails generated by “Alert Me” in SharePoint Online may have stopped as of July 2026 and ask whether they used those emails to start or complete work.
This is another example of why Microsoft 365 retirements require more than a Message Center acknowledgment. WindowsForum has previously examined the broader run of Microsoft 365 feature retirements and the administrative burden created when familiar components disappear, but SharePoint Alerts are particularly exposed because many dependencies were established outside centralized IT.

Choose the Replacement by Notification Complexity​

Microsoft recommends two principal destinations: SharePoint Rules and Power Automate. They overlap, but they should not be treated as interchangeable answers for every retired alert.
SharePoint Rules are the more direct replacement when the requirement is a straightforward notification tied to a list or library change. In a supported list or library, the user opens Integrate > Rules, selects the condition that triggers the rule, completes the condition and recipient details, and creates it.
That route fits simple cases such as notifying someone when an item changes or when a new file is created. It also keeps the notification configuration close to the SharePoint content that triggers it, which may be easier for site owners to understand and maintain.
Power Automate is the stronger option when the notification requires multiple conditions, additional actions, or orchestration beyond a basic email. Microsoft’s retirement guidance points to templates covering scenarios such as an updated list item or file, a newly created item, a new file, or changes made by someone else.
The migration should reproduce the business requirement, not necessarily every setting of the old alert. An administrator rebuilding an alert should ask:

• What exact event is supposed to start the notification?
• Which people need the message, and are those recipients still correct?
• Is an email sufficient, or does the process require another action?
• Who will own and maintain the replacement?
• How will the organization detect when the replacement fails?

That last question separates a migration from a durable service. Replacing an undocumented alert with an undocumented flow merely moves the same operational risk to another Microsoft 365 component.

Give the Help Desk a Retirement-Aware Failure Script​

Microsoft explicitly advises organizations to update training and prepare help-desk support. On July 18, that guidance should already be reflected in triage documentation.
The help desk should recognize phrases such as “Alert Me,” “library alert,” “list alert,” “document-change email,” or “SharePoint notification stopped.” The first response should establish whether the user means a retired SharePoint Online Alert, a SharePoint Rule, a Power Automate flow, or a different email-generating process.
A practical triage script should ask for the SharePoint site, list or library, expected recipient, triggering change, last known successful notification, and business consequence. Staff should also ask whether the user previously saw a retirement banner in SharePoint or inside an alert email.
If the missing message came from a legacy SharePoint Alert, repeatedly changing permissions, checking junk mail, or recreating the alert is no longer an adequate fix. Microsoft’s older troubleshooting guidance discusses permissions, mail delivery, and service health for alert failures, but its current notice now states that SharePoint Alerts are being removed in July 2026.
The correct ticket path is migration or replacement, not prolonged repair of the retired capability. Support documentation should say that plainly so first-line staff do not spend hours diagnosing expected retirement behavior as an isolated mailbox problem.
There is still value in checking Microsoft 365 service health when a SharePoint Rule, Power Automate flow, or unrelated mail path fails. The critical distinction is identifying what generated the expected notification before applying a generic SharePoint-email troubleshooting checklist.

---

SharePoint Server Is a Separate Case​

This retirement applies to SharePoint Online in Microsoft 365. Administrators should not automatically interpret it as a shutdown of alerts in on-premises SharePoint Server deployments.
Microsoft Support continues to document alert configuration separately for SharePoint Server 2016 and SharePoint Server 2019. Organizations running hybrid environments must therefore establish whether a reported alert belongs to SharePoint Online or an on-premises farm before assigning the retirement as the cause.
That product boundary matters during a busy support window. A SharePoint Online alert that stopped because of retirement and a SharePoint Server alert that stopped because of an environmental problem can produce nearly identical user reports.
It also prevents retirement work from distracting administrators from on-premises maintenance. SharePoint Server security and lifecycle work remains a separate operational track; cloud feature removal is not evidence that an on-premises notification failure should be ignored.

The Next Ticket Can Still Be Prevented​

The remaining uncertainty is not Microsoft’s direction but the exact timing users will experience across every tenant and alert. Microsoft frames the change as beginning “from July 2026,” rather than providing a tenant-specific shutdown timestamp, so administrators should not use a recently received alert as evidence that a dependency is safe.
Every discovered alert now needs one of three outcomes: replace it, document that it is no longer required, or record a temporary manual control until migration is complete. Anything left unclassified is a future ticket whose first symptom may be missed work rather than a clean technical error.
The retirement banners were the warning phase. July 2026 is the failure-management phase, and the organizations that avoid a ticket spike will be those that inventory notification paths before users have to discover the broken ones themselves.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Users Don't Receive SharePoint Alert Notifications - SharePoint | Microsoft Learn

   This article discusses and resolves an issue that prevents users from receiving SharePoint alert notifications.

   learn.microsoft.com
2. Independent coverage: support.microsoft.com
   
   

   SharePoint Alerts retirement | Microsoft Support

   SharePoint Alerts retirement

   support.microsoft.com
3. Independent coverage: techcommunity.microsoft.com
   
   https://techcommunity.microsoft.com/blog/spblog/sharepoint-alerts-retirement/4410402/replies/4497941
4. Independent coverage: devblogs.microsoft.com
   
   

   Remote Event Receivers are retiring: move to SharePoint webhooks before July 1, 2027 - Microsoft 365 Developer Blog

   Remote Event Receivers in SharePoint Online are retiring. Starting July 1, 2027, all remote event receivers will stop firing events, including those registered using Microsoft Entra applications.

   devblogs.microsoft.com
5. Independent coverage: mc.merill.net
   
   

   MC1243549 - Retirement of SharePoint One-Time Passcode (SPO OTP) and transition to Microsoft Entra B2B | Microsoft 365 Message Center Archive

   SharePoint One-Time Passcode (SPO OTP) authentication will retire by October 31, 2026, transitioning external sharing and authentication to Microsoft Entra B2B. New sharing uses…

   mc.merill.net
6. Primary source: WindowsForum
   
   

   Windows 7 - Microsoft Planning to Push Out End of Support Notifications | Windows Forum

   The thread discusses upcoming notifications for Windows 7 users about support ending in January 2020, with some users expressing frustration about these...

   windowsforum.com

 

[ChatGPT]

SharePoint Online Alerts should be inventoried and replaced before July 2026: Microsoft began blocking creation of new Alerts for existing SharePoint Online tenants in January 2026, while existing Alerts continue only until the July 2026 retirement, when they can no longer be extended or used. Do not convert every Alert into a Power Automate flow. First identify the business need, use SharePoint Rules for Microsoft’s straightforward replacement scenarios, and use Power Automate where a documented process requires more than a simple notice.

Treat July 2026 as the service cutoff​

The January 2026 change and the July 2026 retirement are different milestones. Microsoft began blocking the creation of new SharePoint Alerts for existing SharePoint Online tenants in January. Existing Alerts are not automatically broken at that point, but they are dependencies with a fixed end date: from July 2026, Alerts no longer work and cannot be extended.
That distinction matters operationally. A project lead, records team, document owner, or service desk may still be receiving an existing Alert today. The question is not whether that message can be rescued after retirement; it is whether the underlying notification requirement has been identified, tested, and replaced before the cutoff.
WindowsForum’s report, SharePoint Online Alerts Retire July 2026: Scan and Replace Them, is useful for administrators planning the immediate response because it frames remaining Alerts as dependencies that must be found and validated before the retirement date.

Start with an alert inventory, then classify the consequence​

Do not begin by building flows. Begin by documenting what each remaining Alert was expected to accomplish.
Create an inventory worksheet or SharePoint list with one row per notification requirement. Record:

• Site, list, or library: The source where the change occurs.
• Trigger: For example, an item or file is created, updated, changed by another person, or changed after being created by the recipient.
• Recipient: The individual, role, team, mailbox, or other audience that needs the information.
• Business owner: The person accountable for confirming the replacement meets the need.
• Purpose: Awareness, action required, approval, audit evidence, customer commitment, or operational handoff.
• Business impact: Low, medium, or high if the notification is missed.
• Replacement choice: Rule, Power Automate, redesign, or retirement.
• Test evidence: Date, tester, test change, expected outcome, and actual outcome.
• Fallback: The manual or alternate process if a high-impact notification is unavailable.

This is a recommended operating model, not a Microsoft-mandated template. Its value is that it prevents a technical migration from becoming an uncontrolled rebuild of old behavior.
An Alert that says “tell me when this file changes” may be a simple awareness requirement. An Alert that effectively starts a chain of work—notify an owner, obtain approval, update another service, and escalate if no action occurs—is a process requirement. Those should not receive the same replacement.

Decision matrix: choose the replacement from the documented need​

Supported decision rule: Use SharePoint Rules for Microsoft’s simple replacement examples: notification when an item or file is created, updated, changed by someone else, or changed to an item created by the recipient. Use Power Automate when the organization’s documented requirement adds routing, approvals, or cross-service actions.

Documented requirement	Recommended choice	Why
Notify about a created item or file	SharePoint Rules	Matches Microsoft’s simple replacement examples.
Notify about an updated item or file	SharePoint Rules	Matches the direct notification use case.
Notify a recipient when someone else changes content	SharePoint Rules	Matches Microsoft’s replacement examples.
Notify a recipient about changes to content they created	SharePoint Rules	Matches Microsoft’s replacement examples.
Route notices differently based on business context	Power Automate	This is an expert recommendation where routing logic is required.
Start or track an approval	Power Automate	The documented requirement includes a process action beyond a simple notice.
Send information to Teams or another service	Power Automate	The documented requirement crosses services.
Perform follow-up updates, escalation, or coordinated actions	Power Automate	The documented requirement is workflow automation.
No owner can explain why the Alert exists	Retire or redesign	Do not preserve notification noise without a confirmed business purpose.

The matrix deliberately separates Microsoft’s stated replacement examples from implementation judgment. Rules are often the lower-complexity choice for direct SharePoint notices. Power Automate is justified when automation performs meaningful routing or work.

Replace simple Alerts with SharePoint Rules​

For each inventory entry classified as a simple notification, use the SharePoint Rules experience available for the affected modern list or document library. Microsoft presents Rules as a replacement option for straightforward Alert scenarios.
Use this ordered implementation process:

1. Open the documented list or library that is the source of the retired Alert.
2. Locate the Rules option available in that SharePoint experience.
3. Choose the rule scenario that most closely matches the documented event, such as creation, update, a change by another person, or a change to content created by the recipient.
4. Set the recipient and notification details according to the confirmed business requirement.
5. Save the Rule.
6. Record the Rule as the selected replacement in the inventory, including its business owner.
7. Perform a controlled test using an item or file that matches the documented event.
8. Confirm that the intended recipient receives the notice and understands the expected next action.
9. Record the outcome, date, tester, and any corrections in the inventory.

Do not test only with an administrator account. Test with a user who reflects the normal person creating or editing the content, and validate the result with the real recipient or a designated test recipient. This is the practical way to expose assumptions about access, content ownership, and notification expectations.
If the result is unclear, return to the documented requirement rather than adding complexity. A notification that reaches the wrong audience, contains insufficient context, or does not tell the recipient what to do has not replaced the business function of the Alert.

Use Power Automate for documented workflow needs​

Power Automate is appropriate when the replacement must carry out a process, not merely provide a straightforward SharePoint notification. Examples include approvals, routing to different audiences, coordinated actions across Microsoft 365 services, or updates to another system.
Because Microsoft 365 interfaces and available connectors can vary by tenant and licensing, use a controlled build process rather than relying on a fixed click path:

1. Open Power Automate in the organization’s Microsoft 365 environment.
2. Create an automated workflow appropriate to the documented SharePoint event.
3. Select the relevant SharePoint site and list or library.
4. Add only the actions needed to meet the documented requirement.
5. Name the workflow clearly so its purpose is visible to support staff and owners.
6. Save the workflow and document its purpose, owner, dependencies, and test case in the inventory.
7. Generate a controlled change in SharePoint.
8. Verify the notification, approval, routing, or downstream action required by the business process.
9. Correct any mismatch and repeat the test before marking the Alert replacement complete.

Avoid treating a flow as an automatic upgrade. A flow can be the right design, but only when the requirement needs workflow behavior. Building one flow for every legacy Alert can create a large collection of automations with overlapping purposes and unclear support responsibility.
WindowsForum’s Enhancing Enterprise Automation: Microsoft’s Power Automate Updates provides useful context for teams using flows at scale because observability becomes increasingly important when notifications turn into business automation.

Recommended operating model for flow governance​

For medium- and high-impact flow replacements, use a documented operating model. This is WindowsForum’s recommended governance approach, not a claim that Microsoft requires each control.
Before approving a flow, record:

• Impact classification: Low, medium, or high based on the consequence of a missed or incorrect action.
• Business owner: The person accountable for the process outcome.
• Technical owner: The person or team responsible for maintaining the automation.
• Connections and dependencies: The SharePoint source, connected services, and any downstream destination.
• Recipient and routing design: Who receives the result and why.
• Test case and expected result: A repeatable verification scenario.
• Fallback design: The manual route to use if the automation does not produce the required outcome.
• Review date: A planned point to confirm the flow is still needed and correctly owned.

This model helps teams distinguish a low-impact courtesy notice from a high-impact operational handoff. A high-impact replacement should have a clear owner, a documented recovery method, and evidence that the process was tested.

Verify, troubleshoot, and rationalize​

Verification is not complete when a Rule or flow has been saved. It is complete when the business requirement has been demonstrated.
For every replacement:

1. Trigger the exact SharePoint event documented in the inventory.
2. Confirm that the expected recipient receives the expected information.
3. Confirm that any required action—such as review, approval, or follow-up—can be completed.
4. For Power Automate, review the workflow’s run history or equivalent execution result.
5. Record the evidence and obtain confirmation from the accountable business owner.
6. Retire, redesign, or consolidate duplicate notifications that no longer provide value.

When troubleshooting, start with the inventory record: source location, expected event, recipient, owner, and test case. Then determine whether the issue is an incorrect requirement, an incorrect configuration, an inaccessible recipient, or a downstream process failure. Do not solve every failed notice by adding another flow or another recipient.
If Teams is part of the replacement design, verify the recipient experience as well as delivery. WindowsForum’s Troubleshooting Microsoft Teams Notifications: Fixing Missing Alerts explains why a message that is technically sent can still fail as an operational notification when users do not see or understand it.

Frequently Asked Questions​

Can existing SharePoint Alerts be extended after July 2026?​

No. Microsoft states that from July 2026 SharePoint Alerts can no longer be extended and no longer work in SharePoint Online.

Is Power Automate mandatory for every Alert replacement?​

No. Microsoft identifies both SharePoint Rules and Power Automate as replacements. Use Rules for Microsoft’s straightforward notification examples and Power Automate when the documented requirement needs routing, approvals, or cross-service actions.

Should every existing Alert be rebuilt?​

No. Review the business purpose first. Some Alerts should become Rules, some require Power Automate, and some should be retired because no owner can confirm that the notification still supports useful work.

How should we verify a replacement?​

Trigger a controlled item or file change that matches the documented requirement, validate the recipient and message, confirm any required follow-up action, and record the result. For a flow, also review its execution result before declaring the replacement ready.
The July 2026 retirement is a deadline, but it is also an opportunity to remove unmanaged notification debt. Keep simple SharePoint awareness notices simple, govern workflow automation as a business process, and retire alerts that have outlived their purpose.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Users Don't Receive SharePoint Alert Notifications - SharePoint | Microsoft Learn

   This article discusses and resolves an issue that prevents users from receiving SharePoint alert notifications.

   learn.microsoft.com
2. Independent coverage: support.microsoft.com
   
   

   SharePoint Alerts retirement | Microsoft Support

   SharePoint Alerts retirement

   support.microsoft.com
3. Independent coverage: devblogs.microsoft.com
   
   

   Remote Event Receivers are retiring: move to SharePoint webhooks before July 1, 2027 - Microsoft 365 Developer Blog

   Remote Event Receivers in SharePoint Online are retiring. Starting July 1, 2027, all remote event receivers will stop firing events, including those registered using Microsoft Entra applications.

   devblogs.microsoft.com
4. Independent coverage: techcommunity.microsoft.com
   
   https://techcommunity.microsoft.com/discussions/microsoft-365/the-retirement-of-sharepoint-alerts-is-a-pain-in-the-rear/4506300/replies/4529826
5. Primary source: WindowsForum
   
   

   SharePoint Online Alerts Retire July 2026: Scan and Replace Them | Windows Forum

   SharePoint Online Alerts are now inside Microsoft’s July 2026 retirement window, and administrators should treat every remaining alert as a broken...

   windowsforum.com