The announcement from Microsoft on 6th July 2020 that SharePoint 2010 workflows were to be retired in M365 tenants from 1st November 2020 means that creating and running 2010 workflows should now no longer be possible. The support article from Microsoft also states that the ability to even view SharePoint 2010 workflow logic via SharePoint designer would be restricted and we would be resigned to view the information as raw XML files only.
During the lead up to this date we’ve worked to convert or rebuild business processes using Power Automate. During planning, we’ve considered alternative workflow solutions but the all-inclusive nature of Power Automate as part of Microsoft 365 is attractive and has meant customers naturally lean towards this option first.
A month on from the SharePoint workflow retirement date (one customer described it as workflow Armageddon) how are things fairing for those that haven’t converted everything in time?
Well, it’s a mixed state to be honest and not entirely unexpected. As we know in the M365 SaaS world, feature deployments rarely happen instantly and the deployment across the multi-tenant architecture means the task to switch off SharePoint 2010 workflows across all tenants in one go is not instant. I also expect Microsoft took note of the current demand on IT teams across the world and decided to unofficially delay the retirement without any PR noise. Either way, it wasn’t until the beginning of December that we started to see workflows begin to stop working and they’ve still been visible using SharePoint Designer, making it easier to translate the logic to a Power Automate solution.
If or when SharePoint 2010 workflows cannot be viewed via SharePoint Designer, one option is to deploy a SharePoint 2019 server farm in Azure and import the workflows. You’ll then be able to view the logic. We recommend 2019 over 2013/16 as the import process is easier and you can be up and running far more quickly. Azure Compute Cost for a trial SharePoint farm 2019 would be roughly £700 if you ran it for 730 hours. That equates to around £0.96 per hour that the machine is running. You could also schedule the machine to shut down automatically at the end of each day and the weekends to ensure costs are minimised.
Planning SharePoint workflow conversions
To plan the workflow conversion effectively, it’s important to run the SharePoint modernisation scanner from Microsoft. Deploy it as an Azure AD app if you can and use the detailed report to export all the details of workflows.
Once you have this report, we found the following info should be gathered through hands-on investigation and communication with SharePoint site owners/members:
- Business process owner
- Complexity (use the workflow action as an indicator)
- Usage (week)
- Running instances
- List item count
- Similarity to other workflows
All the information above can help you estimate the effort required to convert the workflows and also streamline that process. We typically found a small number of people were responsible for the large majority of the workflows created. This meant there were similar workflows and methods used to build the business logic. The teams converting the workflows each performed hands-on discovery and would then report back to each other to identify similarities, plan for Power Automate equivalents and group workflows together that were related to the same business process.
Converting SharePoint workflows to Power Automate
In the creation of the Power Automate flows use the try, catch and finally approach. This is well documented by others such as Tomasz Poszytek, Business Applications MVP and is a great way to build in resiliency to your new workflows.
When converting the workflows to Power Automate, we used a development/UAT SharePoint site. Lists /libraries related to the workflows were saved as a template and then moved to this site, the workflows created in Power Automate and then business owners were able to test and report back. The benefit of this method also meant that InfoPath forms were copied over to the dev/UAT site.
To move the workflows over to the production site, the copy flow feature was used alongside careful planning to disable existing workflows (if they hadn’t been retired yet), or initiate the Power Automate flows to pick up where the old workflows left them (this was typically managed using status column referenced in the workflow logic).
Our recommendations
- Check with the business to see if the workflow process is being used, despite all the reporting data this can sometimes be misleading
- Standardise the structure of your Power Automate flows
- Create a workflow history list and write workflow actions from all workflows in that site (flow history is only stored for 30 days)
- In a list or library associated with a workflow, create a hyperlink column linking to the workflow history list. This link can be structured to filter the workflow history based on the list and current item
- Use a dedicated service account to create the flows with a suitable name/email address
- Ensure your spam filter doesn’t block Power Automate emails from reaching users
- Alert staff that emails from Power Automate will come from either the account used to create the Power Automate or in the case of approvals the email address of the sending account will be maccount@microsoft.com
- SharePoint 2013 workflows will continue to work for the time being, but you may wish to convert these to Power Automate as part of this work
- InfoPath is supported until 2023 this could be a good time to convert to using the modern SharePoint forms or a Power Apps created form
If you would like assistance in converting your SharePoint workflows to Power Automate the Cloud Business team can help with:
- Installing and running the Modernization Scanner
- Analysing workflow complexity and business impact
- Rebuild or redesign of SharePoint workflows in Power Automate
- Power Automate training and best practices
- Ongoing support for Power Platform products
Get in touch or book a discovery call below to discuss how we can help.
