[MS] Remote Event Receivers are retiring: move to SharePoint webhooks before July 1, 2027 - devamazonaws.blogspot.com

On July 1, 2027, Remote Event Receivers (RERs) will stop working in SharePoint Online. After that date, no remote event receiver will fire events, regardless of how it was registered. If your application still relies on remote event receivers to react to changes in SharePoint, now is the time to plan your move to SharePoint webhooks. [alert type="important" heading="Key message"]All remote event receivers in SharePoint Online will stop working on July 1, 2027. Migrate any remaining RER-based functionality to SharePoint webhooks (or Microsoft Graph change notifications) before that date.[/alert]

Background

Remote event receivers are part of the SharePoint Add-in model and depend on Azure Access Control Services (Azure ACS) for authentication. With the retirement of Azure ACS now complete, remote event receivers registered using Azure ACS have stopped functioning correctly as of April 2, 2026. They can still be added programmatically, events might still fire, but inside the receiver service ACS cannot be used anymore for delegated or app-only access back into SharePoint. To give developers more time to migrate, as part of the ACS retirement, we enabled a different registration model that removes the Azure ACS dependency: remote event receivers registered using a Microsoft Entra application. Receivers registered this way continue to work until July 1, 2027, and, unlike Azure ACS–registered receivers, they also work for new tenants onboarded after November 1, 2024. You can read the details in Use remote event receivers without an Azure ACS dependency and the Remote event receivers retirement update. This extension is a bridge, not a destination. On July 1, 2027, both registration models reach end of the road and all remote event receivers stop firing.

Timeline

  • April 2, 2026 - Remote event receivers registered using Azure ACS stopped functioning correctly.
  • July 1, 2027 - All remaining remote event receivers, including those registered using a Microsoft Entra application, stop working. No RER will fire events after this date.

The path forward: SharePoint webhooks

The recommended replacement for remote event receivers is SharePoint webhooks. Webhooks are regular, industry standard, HTTP web APIs, which makes them simpler to build and operate than the WCF services that remote event receivers rely on. When a subscribed event occurs, SharePoint sends an HTTP POST to your service endpoint. A few things to know as you design your migration:
  • Asynchronous only. Webhooks fire after a change has happened (similar to the “-ed” events). Synchronous “-ing” events are not supported, so you can no longer block or cancel an action from a receiver.
  • Blocking scenarios need a rethink. If you used synchronous events to prevent unauthorized updates or deletes, consider securing the protected files and folders so they can’t be changed, or moving the data to a hidden library.
  • Webhooks currently cover SharePoint list items - that is, changes to items in a list or document library.
  • Get the change details yourself. The notification payload tells you something changed, but not what. Call the GetChanges API on the list with a stored change token to retrieve the actual changes.
  • Manage expiration. Subscriptions expire after at most 180 days, so your application is responsible for renewing them.
  • Or use Microsoft Graph. As an alternative, you can use to subscribe to changes on a SharePoint list. If your application needs to stay continuously up to date of changes happening in SharePoint, then please consult the scan guidance for recommended patterns to use.

How to migrate

  1. Inventory your code for remote event receiver registrations and the WCF endpoints that handle them.
  2. Stand up an HTTP endpoint to receive webhook notifications, and implement the validation handshake.
  3. Create a subscription against the target list or library, store the change token, and call GetChanges when a notification arrives.
  4. Re-implement any synchronous blocking logic using the alternative approaches above.
  5. Add subscription renewal so your webhooks don’t lapse at the 180-day limit.
[alert type="note" heading="On discovering RER usage"]Today we do not yet have a way for developers and admins to discover remote event receiver usage across a tenant. This is something we are actively working on, and we will update this blog post, and the associated Message Center post, as soon as it is available.[/alert]

Learn more


Post Updated on June 29, 2026 at 10:32AM
Thanks for reading
from devamazonaws.blogspot.com

Comments

Post a Comment

Popular posts from this blog

[MS] Pulling a single item from a C++ parameter pack by its index, remarks - devamazonaws.blogspot.com

In my earlier discussion of pulling a single item from a C++ parameter pack by its index , I noted that with the Pack Indexing proposal, you would be able to write this to pull an item from a parameter pack while preserving its reference category. template<int index, typename...Args> void example(Args&&... args) { auto&& arg = (Args...[index]&&)args...[index]; using Arg = Args...[index]&&; } Why did I need to apply the (Args...[index]&&) cast ? Why can't I just write this: auto&& arg = args...[index]; or possibly decltype(auto) arg = args...[index]; Well, when you write the name of a variable, the result is an lvalue reference, even if the variable is an rvalue reference . Watch: struct S { S(S&); // construct from lvalue S(S&&); // construct from rvalue }; void whathappens(S&& s) { S t = s; // which will it use? } Try it out in your favorite compiler. This code construc...
Read more

[MS] Boosting Azure DevOps Security with GHAS Code Scanning - devamazonaws.blogspot.com

Image
Debjyoti Ganguly shares insights on the security benefits and configuration of GHAS Code Scanning with Azure DevOps. Boosting Azure DevOps Security with GHAS Code Scanning Code scanning, a pipeline-based tool available in GitHub Advanced Security, is designed to detect code vulnerabilities and bugs within the source code of ADO (Azure DevOps) repositories. Utilizing CodeQL as a static analysis tool, it performs query analysis and variant analysis. When vulnerabilities are found, it generates security alerts. CodeQL CodeQL is a powerful static analysis tool used for showing vulnerabilities and bugs in source code. It enables developers to write custom queries that analyze codebases, searching for specific patterns and potential security issues. By converting code into a database format, CodeQL allows for sophisticated, database-like queries to detect flaws. CodeQL in Action 1. Preparing the Code Create a CodeQL Database : Extract and structure the code into a database for analy...
Read more

[MS] Going beyond the empty set: Embracing the power of other empty things - devamazonaws.blogspot.com

The empty set contains nothing. This sounds really silly, but it's actually really nice. The Windows Runtime has a policy that if a method returns a collection (such as an IVector ), and the method produces no results, then it should return an empty collection, rather than a null reference . That way, consumers can just iterate over the collection without having to deal with a null test. For example, suppose you have a method Widget:: Get­Associated­Doodads which returns an IVectorView<Doodad> representing the Doodad objects that have been associated with a Widget object. If no Doodad s have been associated with the Widget , then it should return an empty vector, not a null pointer. That allows developers to write the natural-looking code: // C# foreach (var doodad in widget.GetAssociatedDoodads()) { ⟦ process each doodad ⟧ } // C++/WinRT for (auto&& doodad : widget.GetAssociatedDoodads()) { ⟦ process each doodad ⟧ } // JavaScript widget.GetAssociated...
Read more