 For Microsoft 365, 2013 has turned into quite the year where Microsoft give it yet take it away like so many other tech giants going on and on and all in on AI. They've given us co-pilot for Microsoft 365 and there's been plenty said about co-pilot already and that's not what I'm going to focus on in this episode. Microsoft 365 has also taken major services away announcing the end of life retirement timelines for three major services throughout the year. SharePoint 2013 workflows in April and recently the SharePoint add-in model in Azure Access Control Services. As a long time SharePoint developer and customer, I understand that these announcements will have a significant impact on all of our work. So in this episode, I want to provide clarity on why I think these announcements were made and what the timeline for the implementation looks like for all of us. It is crucial for us to understand the implications of these retirements and explore different migration patterns to ensure a smooth transition. I'm also going to cover the various tools and services available today that can help us customize SharePoint in a much more modern way. Hi, I'm Andrew Connell and if you're new here, please be sure to hit that subscribe button to stay up to date on all my videos for full stack Microsoft 365 and Azure developers. The SharePoint add-in model was introduced in SharePoint 2013 as a replacement for the fully trusted farm-based solutions and partially trusted sandbox solutions that all developers like us would use to build solutions for SharePoint. Microsoft's motivation for creating this model was to remove developers' code from the SharePoint runtime and to separate SharePoint from hosting all of our custom solutions. The goal was to move the custom solutions for SharePoint outside of the SharePoint process by offering two options, hosting solutions in the client's browser or hosting them outside of SharePoint altogether. This change made SharePoint a more cloud-friendly platform, allowing it to be hosted as a SaaS-based service without customers' code affecting the hosting of the SharePoint service. Now using the SharePoint add-in model, developers could create two types of add-ins. We had SharePoint hosted and provider hosted add-ins. The add-in model relied on Azure ACS, not to be confused with Azure Container Services. This is Azure Access Control Services. I'm going to cover the Azure ACS retirement at the end of this video very briefly. The SharePoint add-in model depended on Azure ACS for security and permissions. Now Azure ACS was used as the app authentication solution at the time SharePoint add-ins were introduced in SharePoint Server 2013, which is what SharePoint was based on at the time for SharePoint Online. Now Azure ACS was used by SharePoint Online to provide authentication for provider-hosted add-ins, and it was used to grant apps access to SharePoint Online with app permissions and granular scopes. But just a few years after SharePoint add-ins were introduced, Microsoft publicly stated that the future of Azure ACS was Azure Active Directory. Now as a quick aside, if you remember from earlier this summer in July of 2023, Microsoft announced a renaming for Azure Active Directory. Azure AD is now referred to as Microsoft Intra ID. That's the new product name for it. You'll see those two names used almost synonymously in various places and the documentation is things that cleaned up. But officially today, as of this episode, Azure AD is called Microsoft Intra ID. Now technically, Azure ACS has been retired since 2018, but it didn't affect SharePoint. You can always refer to this post that I'm showing you here that explains why this retirement didn't impact SharePoint add-ins at this time. Now SharePoint add-ins were not a widely adopted by customers initially or in the following years. Now this was mainly due to the fact that an installation of a SharePoint add-in resulted in the creation of an app web where the SharePoint add-in was actually installed. And the app web was essentially a special sub-site within a site collection. But the challenges putting add-ins in these sub-webs made applying site customizations to existing SharePoint sites a less preferred option compared to the alternative solutions like farm or sandbox solutions or using things like the content editor web part. And what that meant is that customers didn't really rely on SharePoint add-ins to implement many customer requirements. And thus this hurt the adoption and it set Microsoft back to the drawing board. Now eventually Microsoft introduced better ways to customize SharePoint and create apps, particularly through the SharePoint framework. As a result customers started to abandon the add-in model for new projects and opted to use SharePoint framework to address their needs. However many existing add-ins they still remain as they continue to function effectively for their specific solutions that customers created them for. Until the retirement notice was announced and thus it set a finite timeline for these solutions. Now maintaining and running the SharePoint add-in model that has become expensive for Microsoft and it seems that Microsoft wanted to transition existing customers to other options that were more suitable for cloud-based customizations. But customers were limited in their choices as SharePoint add-ins were only the only option for deploying things like SharePoint 2013 workflows and apps that leveraged Azure ACS for authentication and permissions to talk to SharePoint. Now with the deprecation of SharePoint 2013 workflows and the guidance on using Power Automate for workflow-based solutions, Microsoft is now phasing out the add-in model along with SharePoint 2013 workflows and Azure ACS. So what does the timeline look like for the SharePoint add-in retirement or end of life? Microsoft announced the retirement of SharePoint add-ins in November of 2023. In March of 2024 Microsoft will stop accepting new add-in store submissions from customers. This means that you will no longer be able to create and submit new SharePoint add-ins for purchase or installation in other customers' tenants. A few months later in July 2024 customers will no longer be able to install add-ins from the store into their SharePoint online tenants. And additionally, any new Microsoft 365 tenants that are created after November 2024 will not have the SharePoint add-in infrastructure and services enabled and running. This is going to prevent the creation and deployment of custom add-ins directly to the tenant's app catalog or the site catalogs. So that means that starting in November 2024 the only way that you can use SharePoint add-ins will be if the tenant was created prior to November 2024. In this case you can still create and install SharePoint add-ins directly into your tenant using the tenant app catalog or the site collection app catalog. But you can't obtain add-ins from the store. Now approximately a year and a half later in April 2026 that's when the SharePoint add-in infrastructure and services will be shut down across the entire platform including both existing and new tenants in SharePoint online. So what does it mean? It means that you must migrate your add-ins prior to April 2026. Now this timeline it's going to align with the retirement of SharePoint 2013 workflows which will also be shut down in April 2026. And additionally Azure ACS is going to be fully shut off in the Microsoft 365 environments in April 2026. But I'll come back to that later on in this episode. Now that you have a comprehensive understanding of the implications and understanding the what, the why and the timeline of the SharePoint add-in deprecations. Let's explore how we can migrate our existing solutions that utilize SharePoint add-ins to prepare for this transition. Now it's important to start planning ahead even though there are a couple of years before everything is fully retired and shut off. It is crucial to consider the impact that this is going to have in your environments. First let's discuss the SharePoint add-ins themselves as some of the decisions made will directly affect those. Next we'll examine the various types of SharePoint add-ins that can be created. And then we're also going to address the specific scenarios that you may have questions about and how these retirement notices are going to be implemented and how you could address them. SharePoint hosted add-ins allow us to create custom solutions that run entirely in the client's browser. This means that our JavaScript, images and HTML are all deployed and hosted by SharePoint and SharePoint simply loads them in the browser when it's requested. So at a high level if you have a SharePoint hosted add-in it's recommended that you migrate your project to use the SharePoint framework because both SharePoint hosted add-ins and the SharePoint framework deploy their code including HTML, JavaScript and images to SharePoint which is then going to serve them up in the client browser. Also when a user visits a page where the solution is being used the actual application runs in the user's browser, again not in the server. Because both of these solutions run exclusively in the browser they inherit the same sign-in credentials of the current user and do not support scenarios such as elevating privileges. Both SharePoint hosted add-ins and the SharePoint framework can be installed from the SharePoint store or side-loaded to the various SharePoint app catalogs for deployment, development and testing purposes. Now I cover the SharePoint framework extensively in my course Mastering the SharePoint Framework. If you're interested in learning more about this check the notes below the video and in this episode to learn more about that course. And if you're migrating reach out to me I'll give you a special discount on the course as well. Now let's discuss SharePoint provider hosted add-ins. A provider hosted add-in is registered with your SharePoint deployment and your site collection. It requires you to deploy all the code to your own cloud resources. For example if you have created a web part as a SharePoint provider hosted add-in you're going to set it up as a website solution and deploy it as a cloud resource using something like an Azure web app. The most important point here is that you as the developer are responsible for deploying and hosting the SharePoint provider hosted add-in separately from SharePoint. Now if you decide to rebuild your SharePoint provider hosted add-in as an API there are various options for deploying the code such as using Azure Functions, Azure Web Apps, Azure Container Apps and many other non-Azure options and solutions. Now ideally you should secure the endpoint where the SharePoint provider hosted add-in is hosted using Microsoft Intra ID. Now if you have a web part that is part of your SharePoint provider hosted add-in you're going to need to port that as a SharePoint framework based solution as well. Now the SharePoint framework can then call your custom API using the SharePoint framework's HTTP client API if the API is anonymous and unsecured. If it is secured you can use the Azure AD HTTP client object if it's secured using Microsoft Intra ID. Now to retrieve data from your SharePoint site with your new SharePoint framework web part or any other SharePoint framework component for that matter you're going to use the SP HTTP client API to make requests to the SharePoint REST API or you can use the Microsoft Graph client API from the SharePoint Frameworks API to retrieve data from SharePoint using Microsoft Graph instead of using the SharePoint REST API. Additionally there are other options available for retrieving data such as using the popular open source library P&PJS which can use both the SharePoint REST API and the Microsoft Graph REST API to retrieve the same data. It's just another option for accessing data and it's up to you if you want to use it. Now that we've discussed some of the high level considerations let's examine some specific scenarios that you may encounter with migrating your SharePoint add-in based project. It's important to note that many of these SharePoint add-ins were built years ago and may utilize older technologies that were available at the time but have since changed or been retired. So let's start by discussing some data access scenarios. Now previously to retrieve data from SharePoint lists and libraries you may have been using a camel based query. That's a collaborative application markup language. It's an XML based language that is used to submit queries to SharePoint endpoints. You might have also used the client-side object model also known as the CSOM or the JavaScript object model known as the JSON to issue these requests and queries that were written in camel. But going forward it's much more recommended to replace these technologies with REST based OData queries and you can achieve this using any of the APIs that are provided with the SharePoint framework as I previously discussed in this episode. Now if you're working with a SharePoint specific endpoint you can also use the Microsoft Graph client API in the SharePoint framework SDK which is going to leverage Microsoft Graph to get access to the same data. Now if you're using Azure ACS for your custom solution and need app-only permissions you're going to need to migrate to Microsoft Intra ID and you can learn more about how to do this using this article that I'm showing you for guidance. Now one thing to note is you will see this article referred to Azure AD and Azure Active Directory just know that that is now called Microsoft Intra ID. Now for apps that leverage granular permissions using Azure ACS that allows you to grant things like read, write, manage and full control permissions to specific site collections you're going to have to take a different approach because Microsoft Intra ID by default is going to grant these permissions to all site collections in your target tenant. So to work around this you can use something called resource specific consent also known as RSC. Now in this scenario you're going to register your Intra ID app and grant it permissions to specific site collections similar to what you did with Azure ACS but you're going to use a special permission scope called sites.selected. Now let me talk a little bit about these things called app parts. SharePoint app parts enabled us to create web parts using the SharePoint add-in model that can be used in the host web of our site collections and these app parts should be rebuilt as SharePoint framework client-side web parts. SharePoint add-ins also allowed us to customize a classic site's list or library ribbon bar by adding buttons or to the context menu on a list or library that's also referred to as the edit control block or ECB menu. Now these customizations should be rebuilt using the SharePoint frameworks list view command set extensions but unlike the SharePoint add-in the new SharePoint framework supports other types of customizations for lists and libraries such as creating field customizers that replaces the old JS link technology we used to use and list form customizers where you can replace the new or edit forms with SharePoint framework-based forms. Now let's discuss a really big topic, remote event receivers. Now we can break them down into two different categories but first let's talk about some common aspects that we need to consider. Remote event receivers allowed us to receive notifications when events occurred in lists or libraries and apps as well as during the application lifecycle with our SharePoint environment. Furthermore, remote event receivers provided us with a SharePoint context when they were called. Now these supported both asynchronous and synchronous events and this synchronous capability of some remote event receiver events enabled us to block certain events or items from being added or edited in our registered lists and libraries using the SharePoint add-in model. Now although these remote event receivers have not been recommended for a long time they still work but the current recommendation is for developers to transition to using webhooks such as SharePoint webhooks or Microsoft Graph webhooks. Now however there are some differences worth noting between remote event receivers and webhooks I'm going to cover that in the next section. Now let's look at two different scenarios when it comes to using remote event receivers for lists and libraries. Now we used to have the ability to handle both synchronous and asynchronous events as I mentioned a second ago but in SharePoint and Microsoft Graph only asynchronous events are supported. This means that we can only work with remote event receivers to receive notifications when an item is added to a list or edited on a list. We can then run some logic to determine if the item should be saved or not. Now that's only with remote event receivers. Unfortunately I can't use remote event receivers or webhooks for custom data validation. Unfortunately we can't use remote event receivers or webhooks for custom data validation requirements. I was a common use case for the remote event receiver synchronous events that addressed for us. Webhooks are inherently asynchronous meaning they only notify us after something has already happened. There is no synchronous option available for us to migrate our solutions to and thus we're going to have to explore different alternatives that we can come up with for implementing those data validation checks. But just know there is no solution today to block something from being added to a list or be edited from using one of these event models here. We're just going to have to come up with a different way to solve that business requirement. Now another difference is that we don't receive any data or context when an event occurs and depending on the specific event we're listening for we're simply informed that something happened to retrieve the data for an item being added to a list. Now we can use the Microsoft Graphs data query capability to retrieve the changes that have happened since the last time I ran that query. Now if I was previously using remote event receivers for listen libraries I'm going to need to migrate those solutions to use either webhooks from SharePoint or webhooks from Microsoft Graph. Now these webhooks are set up on a subscription basis so you subscribe to the specified event and then are notified when those different events occur. Now it's important to note that you're going to need to maintain the subscription as it will expire and be removed by Microsoft automatically. So be sure to keep track of the subscriptions lifetime and renew the registrations accordingly. Now let's discuss the other type of event that we had with remote event receivers, app lifecycle events. Now the app lifecycle events included app installation, uninstallation, and upgrades. And these three events with these three events SharePoint can notify a remote endpoint whenever an app was installed, uninstalled, or upgraded. And they allow us to perform various actions to implement different solutions such as creating a list or a library for the app or executing a provisioning process when the app was installed or maybe even a cleanup process when the app was uninstalled. Unfortunately there's no published app lifecycle event available to us with SharePoint framework and Microsoft Graph based webhooks. And this is a feature that I've been begging Microsoft from for a long time. So if you want this feature, it's important to let them know about your interest for it as well so that they can prioritize it. In the meantime, if your solution requires an additional setup after installation or cleanup, after the uninstallation, you're going to need to implement a process that checks if the prerequisites are present. For example if they're not present, you can provide an alternative setup experience using the client side code on the first run of like a web part or an extension. This code can then perform operations if the current user has the necessary permissions like creating a list. But if not, you can alternatively use client side code to call a remote API that you create. Within that remote API, you can use Microsoft Intra ID to obtain an access token with elevated permissions and then use that access token to authenticate against SharePoint REST APIs or the Microsoft Graph APIs to perform the necessary elevated operations. For the sake of completeness, I do want to briefly discuss the retirement of Azure ACS. The retirement of Azure Access Control Service follows the timeline that is very similar to the retirement of the SharePoint add-in model and the retirement plan for SharePoint 2013 workflows. The retirement plan was announced on the same day as the SharePoint add-in November 27th, 2023. So here's how it works. In November 2024, any new tenant created for SharePoint Online or Microsoft 365 will not have Azure ACS enabled. This change only applies to tenants that were created after November 2024. Existing tenants created prior to November 2024 will still be able to use Azure ACS. Then in April 2026, Azure ACS will stop working across all tenants in Microsoft 365. This is the same time that the infrastructure and services that support the SharePoint add-in model and SharePoint 2013 workflows is shut off. Why? Because they all are related to each other. In order to be able to use a SharePoint add-in, you are in use the permissions associated with an add-in, you set up the permissions using Azure ACS. To deploy a workflow, you have to deploy a workflow using a SharePoint add-in model. So when ACS goes away, the add-in model has to also go away and the SharePoint 2013 workflows, again, they also have to go away as well. And that's why they're all being retired and reaching end of life in April 2026. So what guidance do I have for preparing for the retirement of Azure ACS and how should you migrate these solutions? Well, we used Azure ACS in two different ways to obtain tenant-level permissions or site-collection-level permissions in our SharePoint sites. For an app-based permission for SharePoint, such as sites.read.all or termstore.read.all, it's recommended to use the sites.selected permission to apply specific permissions to a subset of site collections instead of having those permissions applied to the entire tenant in all site collections in the tenant. But to obtain permissions for just lists or sites on a granular level, you're going to use resource-specific consent, RSC. Now that's currently a work in progress and it will allow applications to access only a specific SharePoint site or list instead of entire site collections. Now this specific feature is not yet available in production as it's currently under development. So what do you think about the retirement plans for SharePoint 2013 workflows, Azure ACS and the SharePoint add-in model? Now I've only covered some popular aspects that often arise when people migrate from their existing SharePoint solutions that utilize SharePoint 2013 workflows, Azure ACS or the SharePoint add-in model to newer, more modern supported patterns and technologies. I am sure that there are plenty of scenarios that I have not addressed in this episode. So what specific scenarios are you interested in? What aspects would you like guidance on as you move forward? Let me know by dropping a comment below the video or schedule a 101 call with me. I would be more than happy to discuss your projects with you and help guide you in your migration as I offer coaching and consulting services as well. Now I reference a lot of links in this video and you're going to find all of them in the article on my site that I've linked to in the description below the video. Now if you found this video useful, please give me a thumbs up and subscribe by smashing that big subscribe button below the video. So you'll see when I publish more videos for full stack developers on Microsoft 365 and Microsoft again. I'm Andrew Connell. Thank you for tuning in and I'll see you in my next episode.