The end of SharePoint 2010 workflows

On July 6, Microsoft announced that they will be retiring SharePoint 2010 workflows from November 1, 2020. I decided when reading the news that I would hold fire on writing something just to let the dust settle a little bit.

So after being inspired by John Liu’s blog post, I’ve decided to keep my own rolling list of resources to help myself and hopefully others transition from SharePoint 2010 workflows to Power Automate.

Background

Microsoft had stated in 2016 that support would continue for SharePoint 2010 workflows until 2026, but with this month’s announced they specified that:

– Starting August 1st, 2020, SharePoint 2010 workflows will be turned off for newly created tenants.  

– Starting November 1st, 2020, Microsoft will begin to remove the ability to run or create SharePoint 2010 workflows from existing tenants.

Support update for SharePoint 2010 workflows in Microsoft 365

This applies to both out-the-box and custom SharePoint 2010 workflows, but only in Microsoft 365. If you are still on premises this does not apply to you as they are still being supported until 2026 at the time of writing, but I imagine you have your own issues to deal with!

For SharePoint 2013 workflows, Microsoft announced they will remain supported, but depreciated. So that means that SharePoint 2013 workflows will be turned off by default for new tenants starting in November 2020, but Microsoft will provide a PowerShell script to activate the workflow engine. 

What does this mean?

Unless Microsoft has a change of heart, what this means is that over the next 4 months all SharePoint 2010 workflows will need to be re-developed using Power Automate, Nintex or any other another third-party workflow solution.

Microsoft offer a modernization scanner that (amongst other things), will understand where “classic” workflow is being used and sort of grade them based on number of actions and complexity. However, this scanner only works for SharePoint Online, so if you’ve yet to migrate to Microsoft 365 you will need to use another assessment/ inventory tool to get this sort of information about your SharePoint 2010 workflows.

What I’m going to do

So for myself, my organisation has several SharePoint 2010 and Nintex workflows on premise that have yet to be migrated to Microsoft 365 and are largely still in use.

As part of discovery work conducted previously, I’ve used a combination of ShareGates site report to get the high level information about my sites(s), the SharePoint Migration Assessment Tool to get information about my SharePoint workflows and a PowerShell script to get similar information about the Nintex workflows.

Even with a complete list of SharePoint 2010 workflows, there is still some documented pain points that will require some thought to overcome – this won’t be a straight copy/ paste into Power Automate 😀

However, with that said the plan is essentially the same as before; assess the active workflows, consolidate where possible and re-build the SharePoint workflows in Power Automate – only in a much shorter time frame…

Resource list

I will keep updating this list as I see new articles, or information from Microsoft and others.

Background information

Guidance and other useful info

Tools

Advertisement

Finding the task properties pane in SharePoint 2013 workflows

(this post was written using a SharePoint online environment and SharePoint Designer 2013)

So here’s the scenario, there is a central list where users add items and once submitted a workflow runs that assigns tasks to separate task lists. No big deal right?

The scenario

Task actions in SharePoint 2013 workflows are a pretty standard thing, the example above just assigns tasks to different lists (think HR, IT, Pensions) for work to be completed. The additional requirement I had was for these tasks to not send any system generated assignment emails when the tasks are assigned.

Example of creating & assigning a task in a SharePoint 2013 workflow.

The problem

This one really had me pulling my hair, but in a nutshell there is no obvious way to turn on/ off the emails that are system generated at the point which a task is assigned.

When you double-click on a task, an “Assign a Task” window opens. Within this window there is an “Email options” drop down, but this only has the email editor for the task creation email and the ability to turn on/ off the task overdue email(s). It doesn’t have any settings for switching on/ off the initial emails themselves.

The Assign a Task window doesn’t contain the properties to switch off system generated emails.

The hidden task properties pane

So at this point I began thinking there is no way to do this and the design for this process is now fundamentally flawed…until I right-clicked!

If you right-click on the list within the assign task action (the ICT Task List Members bit underlined in the example below) a menu will appear. Normally this menu contains some simple options like moving an action up or down. However, with task actions there is an additional option called “properties”.

Hidden properties button within the “assign a task” action.

After clicking on the “Properties” button, you’ll find an additional “Assign a Task Properties” window which contains the following, hidden properties:

Hidden assign a task properties window.
  • PreserveIncompleteTasks: set to true if you want non-completed tasks to be deleted when the task process is complete.
  • WaiveAssignmentEmail: set to false if you want to have an email sent out to the assignee when a task is created
  • WaiveCancelationEmail: set to false if you want to have an email sent out to the assignee when a task is canceled.

By default, all of these properties that are set to “no” or “false”, so will send emails based on the above parameters. To change, just click on the drop down next to each option and update to “yes” or “true” and the emails will stop sending!