SharePoint deadline

SharePoint remote event receivers retirement: what stops on July 1, 2027, and what replaces it

By the MMM team — November 8, 2026

The SharePoint remote event receivers retirement has two dates. Receivers registered through Azure Access Control Services (ACS) stopped working correctly on April 2, 2026, along with SharePoint Add-ins. Every receiver still running, including those registered with a Microsoft Entra ID app, stops on July 1, 2027. This guide covers that second, final cut-off: who it reaches, how to find your receivers, and how to choose between SharePoint webhooks and a Power Automate flow for each one.

The April 2026 deadline has its own page: our SharePoint Add-in to SPFx migration services cover rebuilding add-ins, and the receivers that went down with ACS, as a fixed-fee project. This article is about the receivers that survived April because they were moved to Entra ID, and about the decision each of them now needs. Every Microsoft statement below was checked against Microsoft’s published announcement and documentation on November 8, 2026.

What exactly stops working on July 1, 2027?

From July 1, 2027, SharePoint Online no longer calls any remote event receiver, whatever app registration it uses. Code that ran when an item was added, updated or deleted, or when a list or site changed, simply stops being invoked. The list keeps working; the side effect the receiver produced silently disappears.

Microsoft set out both dates in its Microsoft 365 Developer Blog post, Remote Event Receivers are retiring: move to SharePoint webhooks before July 1, 2027 (opens in new tab). It names SharePoint webhooks as the recommended replacement, with Microsoft Graph change notifications as an alternative. Here is how the two dates apply:

Who is affected by the cut-off?

Any Microsoft 365 tenant where custom code reacts to SharePoint list, library or site events through a remote event receiver. That usually means a provider-hosted add-in, an older integration built by a partner, or a PnP-provisioned solution that attached receivers to lists. Out-of-the-box SharePoint features, SharePoint Rules and Power Automate flows are not remote event receivers.

The hard part is that nobody may remember the receiver is there. It was attached to a list years ago, it points at a web service someone else hosts, and it has quietly stamped a field, moved a file or updated another system ever since. The first sign of trouble on July 1, 2027 will be a business process that stops without an error message: invoice numbers not assigned, documents not filed, a downstream system no longer updated.

How do you find the remote event receivers in your tenant?

When Microsoft announced the cut-off, it had no tool to discover remote event receiver usage and said one was being worked on. Until one ships, enumerate the event receiver collections on your sites and lists with PnP PowerShell or CSOM, and look for receivers whose address points at an external web service.

1. Enumerate receivers. For each site collection, read the event receivers registered on the site, its webs and every list. PnP PowerShell’s Get-PnPEventReceiver does this per list or per scope; CSOM exposes the same EventReceivers collections.
2. Keep only the remote ones. A receiver with a ReceiverUrl pointing at an https endpoint is remote. Receivers implemented in an assembly belong to SharePoint itself or to old farm solutions and are not part of this inventory.
3. Record the event type. Note whether each one is synchronous (“-ing”) or asynchronous (“-ed”), and on which list, library or site it fires.
4. Find the code and an owner. Trace the endpoint to its hosting, its source code and the app registration it uses. A receiver nobody can explain is a candidate for retirement, but confirm with the list owner first.
5. Describe what it does in one sentence. “Stamps a contract number”, “copies metadata to the ERP queue”. That sentence drives the choice below.

Should you move to webhooks or a Power Automate flow?

Choose webhooks when a developer-owned service already does the work and only the trigger has to change: the code stays, the plumbing is replaced. Choose a Power Automate flow when the receiver did something a business user could describe in a sentence, such as copying metadata, notifying a team or updating another list, and nobody wants to maintain hosted code.

The webhook rows come from Microsoft’s overview of SharePoint webhooks (opens in new tab), which also notes that webhooks are currently enabled only for list items. A receiver that watched site-level events has no webhook equivalent and needs its own design. Many tenants end up with a mix: a handful of webhooks for the developer-built integrations and a set of flows for the rest, plus a few receivers retired outright.

What happens to synchronous receivers that blocked changes?

They have no direct replacement. Webhooks and Power Automate both react after a change is saved, so neither can cancel an add, update or delete the way an ItemAdding or ItemUpdating receiver could. Rules that used to block bad input have to move to column validation, required fields, permissions or a corrective step after the fact.

Microsoft’s own guidance for this case is to use alternative approaches, such as securing the files and folders that a receiver used to protect. In practice, work through each blocking receiver and ask what it was preventing. Bad values often belong in list or column validation; “nobody may delete this” usually belongs in permissions; and some checks are acceptable as a flow that corrects or flags the item a moment later. These are design decisions, not ports, so start them first.

How does this relate to the SharePoint Add-in retirement?

The add-in retirement on April 2, 2026 took ACS-registered receivers down with it, and our SharePoint Add-in to SPFx migration services page covers that rebuild. This deadline is the later, separate one: it ends the receivers that survived April 2026 because they were registered with Entra ID, and Microsoft has announced no alternative registration route.

It is also one of several SharePoint features being retired in the same period. If the receivers you find were mostly sending emails, the same Rules-or-flow choice is set out in our guide to the SharePoint alerts retirement. Organizations that still run an on-premises farm have a separate deadline in the Office Online Server retirement; remote event receivers in SharePoint Online are not part of that change.

What should you do before July 1, 2027?

Inventory every receiver now, decide webhook, flow or retire for each one, and rebuild in a test site before touching production. Start with the synchronous receivers, which need a design change rather than a port, and switch off each old receiver only after its replacement has been proven on real changes.

1. Inventory. Every site, web and list, with event type, endpoint and owner, as above.
2. Decide per receiver. Webhook, flow, redesign or retire, written down with a reason.
3. Rebuild in a test site. Test bulk uploads, rapid repeated edits and changes made by the new solution’s own account; those expose loops and duplicate actions.
4. Cut over one receiver at a time. Remove the old receiver when its replacement goes live, so the same change is never processed twice.
5. Own the result. Put webhook renewal on a schedule and flows on a service account, and document who to call when either stops.

Where flows are the answer, our Power Automate consulting practice builds and documents them in your tenant. Where webhooks are, the work sits under SharePoint consulting. Either way it is scoped and priced before anything starts, delivered by senior US-based Microsoft engineers, typically within 2–4 weeks, with 30 days of hypercare afterwards. We are based in Orange County, California, and work with businesses across the US remotely. See how the fixed-fee process works.