On Monday 7/6/2020 Microsoft announced the end of support for SharePoint 2010 workflows and the deprecation of SharePoint 2013 workflows in SharePoint online effective August 1st – November 1st, 2020.
SharePoint 2010 and SharePoint 2013-based workflows will continue to be supported for on-premises SharePoint 2016 and SharePoint 2019 Server platforms until 2026.
The time to convert your SharePoint 2010 workflows is now!
If you are running SharePoint 2010 workflows in SharePoint Online, you need to take some sort of action, quick! The recommended action is to convert your SharePoint 2010 workflows to Microsoft’s cloud-based Power Automate (the actual set of actions is called a Flow). Fortunately, each internal Microsoft 365 license is already licensed to use Power Automate and Power Apps when these applications are running against SharePoint. (Additional license charges apply when using these tools to connect to external systems).
Although Microsoft does not have a conversion tool, they do provide some modest assistance in locating and identifying a SharePoint 2010 workflow and evaluating its complexity. Examining the “Workflow Report” from the SharePoint Modernization Scanner tool will give you an idea of where the workflows are located and their “upgradability score”.
The “upgradability score”, indicates the number of actions in your current workflow that have a parallel action in Power Automate (Sending an email, updating a list item, REST call, etc.)
I don’t think upgradability is a good name for this score, conversion score or migration score would be more accurate names. This is because in many cases, even though there is a Flow action which is equivalent to a SharePoint 2010 action, the workflow may need a complete redesign due to the way Flow executes the action.
The Kiefer Approach: Converting a SharePoint workflow to a Power Automate Flow.
Kiefer Consulting uses the following guidelines to convert SharePoint 2010 workflows to Power Automate Flows:
- Identify the all workflows (use the SharePoint Modernization Scanner Tool’s Workflow Report)
- Review the workflows to determine how heavily they are used
- Review the “Upgradability Score” (in the Workflow Report) to determine the conversion’s complexity
- With the usage and upgradability score, prioritize the order of workflows to be converted to Flow
- Starting with the highest priority Flow:
- Get business user involved and prepared to perform User Acceptance Testing (UAT)
- Review the existing SharePoint 2010 workflow; understand what the workflow is doing
- Redesign workflows as appropriate (see next section)
- Construct Flow
- Test Flow
- UAT Flow (business user testing)
- Resolve bugs
- Go Live
What you need to know about converting SharePoint 2010 workflows to a Power Automate Flow.
Microsoft is somewhat cavalier about the differences between SharePoint 2010 and Flow. These differences are fundamental to the way a Flow executes. These differences, along with Flow’s boundaries and limitations may add more development and testing time to a conversion.
The differences in the way a Flow is triggered, when a Flow executes, how a Flow loops loops, how the Flow is bound to a list, and many others, can make a substantial difference in the conversion effort. Below are the big “gotchas” when converting a SharePoint 2010 workflow to a Power Automate Flow.
Execution conditions have changed.
SharePoint 2010 workflows start conditions are “Manual”, “Creation” or “Change” (8 different conditions) on a list item. MS-Flow can be triggered on “Creation” or “Creation and Change” (2 different conditions) on a list item. Since a Flow can only have 1 trigger, and you want the Flow to only run on Change, you need to add code to exit if the item is new. If you want the same Flow to run based on a manual trigger or a created item, then you will need two different Flows (easy to copy, but harder to support) or three Flows, one for each of the triggers and a third to run the common business logic (This will actually cost you more since you will need a premium connector to run a Flow from a Flow). There are other scenarios that you may need to evaluate because of this change in trigging.
Flows can only be active for 30 days.
Long running workflows are a thing of the past. If your workflow runs over the course of more than 30 days, you will need to break it into discrete units of work, using a saved state in the list item to determine the next set of actions.
MS-Flow is triggered by a web-hook rather than an event receiver.
Forgetting the technical jargon, this means that a Flow triggered by an item’s “Creation and Change” may not execute the way you planned. Consider an item modified once; the Flow is triggered and executes as planned. Now consider an item that is modified once and then quickly modified again. The Flow will run with the data from the second modification, that may not be a big deal, unless you are trying to compare data in the current item with data in the previous version of the item. Now consider an item which is modified 3 times, will the Flow run after the first modification, the second modification or the third modification? You cannot tell. The Flow may run once with the data from the third modification, or it may run twice with the data from the first and third modification, or data from the second and third modifications, or it may run three time, once on data from the first modification, the second with data from the second, and a third time with data from the third modification. You may think that this is a rare occurrence, but actually happens very frequently with the new Modern sites, as items updating a single field updates the item immediately, so updating 3 fields will save the record 3 times, and send 3 web-hooks to the Flow, and the Flow may run one, two or three times.
Multiple Flows can run on the same item at the same time.
In SharePoint 2010 workflows only one workflow instantiation per subscription per item run could run at a time. The design nature of Flow allows multiple Flows to run on the same item at the same time.
Some MS-Flow actions are bound by the list view threshold (5000 items).
When creating Flows, you will need to filter results returned by lists to the bare minimum. Many actions in Flow are limited to 5000 items.
MS-Flow is bound by 500 actions.
Currently only 500 actions are permitted in a Flow. This can be worked around by breaking up the Flow into sub Flows. This activity will require more design effort and possibly premium licenses.
MS-Flow connectors to external data sources may require a premium license.
While using Flow against SharePoint is included in Microsoft 365 licenses, connecting to external systems and data sources will probably cost you more.
Breaking a MS-Flow into sub Flows will require a premium license.
The simplest way to break a Flow into sub Flows will require the use of a HTTP connector that connects outside of SharePoint. This is a premium action.
Large if statements are limited.
Flow does not allow you to nest statements greater than 8 levels.
Looping is limited.
Aside from the fact that looping is extremely slow, looping commands are limited to 5000 items/iterations. This limitation can be upgraded with additional licensing.
Flow is Item centric – There is no “reusable workflow” concept.
Much of the citizen-developer experience is centered on processing a new or updated item in a specific list, similar to a SharePoint 2010 list workflow. A reusable SharePoint 2010 workflow can scale out and can be used on multiple lists. While there are techniques to use the same Flow logic across multiple lists, it will cost you design effort as well as a premium connector (Http connector).
Updating the triggering item will re-trigger the Flow.
If your SharePoint 2010 workflow executes on an item’s change, and, during the execution, updates the status of the item, it is not a problem since only one workflow instance per workflow subscription per item can run at a time. This is not the case for Flow. If your Flow is set to run on “Creation or Modification”, then modifying the triggering item within the Flow will trigger another instance of the Flow. At the top of the Flow, logic is needed to test if the Flow should run and terminate if it doesn’t meet those conditions. This can be a particularly nettlesome problem, usually resolved by augmenting the list to include a column that indicates the last status of the Flow. This status is compared, at the top of the Flow, with the current status to determine if the Flow should continue to execute.
Flow runs under the Owner’s Connection Permissions.
A SharePoint 2010 workflow executes under a system account and can access “elevated permissions” to add, change, read, or delete items. Flow runs under the Flow’s Owner’s permissions. If the owner has read permissions to an item, but does not have change permission, the Flow will fail when it attempts to update the item.
The easiest way to convert SharePoint 2010 workflows.
As you can see, there are a lot of “gotchas” and moving the workflows from SharePoint 2010 to Power Automate Flows will require expertise that you may not have in-house. Kiefer Consulting can help. We can help you in moving existing workflows or help you architect new workflows in SharePoint. Contact us to learn more.
Check out our next blog. We will be sharing Power Automate best practices!