I’ve been through quite a few SharePoint Migrations, and I wanted to share some of the gotchas I’ve seen when converting SharePoint 201/2013 workflows to Power Automate. This isn’t an exhaustive list by any means, but hopefully this information may come in handy for either IT professionals who are recreating these workflows, as well and Business users who may not understand what they’re getting with the new Power Automate Workflows.

Power Automate isn’t just for SharePoint

SharePoint 2010 and 2013 Workflows were really designed to be used in SharePoint only. Sure, there were use cases where you may have pulled in data from external sources, but at the end of the day, these Workflows were created in SharePoint, ran in the SharePoint farm, and respected SharePoint permissions exclusively.

Power Automate on the other hand, is designed to be platform agnostic and allow IT and Business users to create very robust workflows that can connect to many disparate data services (licensing permitting). For users coming from a completely SharePoint centric world, this concept can be difficult to grasp, especially for End Users. While there is tight integration between SharePoint and Power Automate, educating end users on the real power and flexibility of Power Automate can help drive their automations to a whole new level.

Educating your End users on the differences between Power Automate Cloud Flows and SharePoint Workflows is essential before beginning any migration/recreation. The way they used to do certain things will change when moving to SharePoint Online/Power Automate, and it’s important they understand some key differences before you find yourself in a migration quagmire. I’ll highlight some of those key differences below:

Workflow History

When you created a Workflow in SharePoint on-prem, a default “Workflow History” list was created as well. Typically, this list was abstracted from end users, however they could view the data located in this list by viewing the history on their Workflow. This was especially useful for savvy end users who wanted to see specific information that may have been logged either by default, or by specific custom actions in a SharePoint Designer workflow. Many end users relied on this information for Auditing purposes, or for even seeing where in the approval process everyone’s responses currently stood.

Most SharePoint Migration won’t pull over this information as it’s difficult to get to and will never tie into any workflows going forward. It’s important to educate end users on the ramification of this as well as inform them that this type of functionality doesn’t live in Power Automate by default. Sure, you can view the “Run History” of a Power Automate flow, but IT professionals should be prepared to accommodate users who may not understand how to parse a Run history, as well as be prepared for the fact that end users may not even have access to Run history on flows.

Task Lists

SharePoint 2010/2013 Approval Workflows relied Heavily on task lists to create approvals, provide end users a place to Approve/Reject items, and provided notifications to end users automatically throughout the process. Power Automate has streamlined the Approval process through the Approvals actions.

When recreating these Approval workflows you can provide a much better experience for end users this way, however it’s also a big change for users. They may not understand how this impacts them, and what the consequences of moving away from Tasks might be. This is especially true if they use these task lists regularly and rely on the historical data from them. While you can easily migrate the Tasks lists, the functionality around notifications goes away once they are in SharePoint Online. All the notifications end users expect to get around Approval due dates, reminders, etc., will all have to be recreated in Power Automate.

Who am I waiting on to Approve that item?

SharePoint 2010/2013 Workflows allowed you to easily see what users had Approved/Rejected an item and who was still outstanding on their approvals. This information can be found in Power Automate, however it’s not easy or intuitive for end users to find. This particular information lies in the “Approval Responses” table in Dataverse, and in order to present it to your users, you’re going to have to build that functionality into your Power Automate flow and write it out to either a custom field on the list item, or to a sperate list in SharePoint. This can a time-consuming development process if you’re not familiar with it, so ensuring you inform end users prior to Development on what the level of effort might be, will help put you in good graces with them. Also, when designing this type of workflow, it will be important to set expectations on how often that information can be polled from Dataverse, if this is a long running approval process, polling every minute may not be sustainable for this type of process.

SharePoint 2010 default Workflows

One area that gets easily overlooked during a migration is users who may have leveraged the “out-of-the-box” SharePoint 2010 workflows for Approvals or 3-State Workflows. When performing a discovery on the on-prem SharePoint farm, it’s important to note that users may be using these and plan for any “unexpected workflows that nobody knew about until migration day” that pop up. Make sure you leverage the SharePoint Migration Assessment Tool (SMAT) which can help you identify these workflows.

From: Address in Workflow Emails

SharePoint on-prem, in tandem with Exchange on-prem typically let you send emails from any address a user wanted to: (i.e. ‘No-reply-Seriously@company.com). Office 365 is different whereas an email must come from a REAL email address that is hosted in Exchange Online. Depending on how the Power Automate flow is constructed, it may run as the user who executed the workflow, or the owner of the workflow. This may be the From: address that shows up when a user receives an email from the workflow, so it’s important to plan accordingly to ensure users are satisfied with whom they’re getting email from. In addition, some Actions use a default Microsoft address (i.e. Approvals), so you may also need to ensure that that email address has been whitelisted in Exchange so Approval emails don’t wind up in the Junk Email folder.

Long-Running Workflows

You may find instances where users would kick off a Workflow on SharePoint on-prem, and it could run for more than 30 days. Power Automate has a strict 30 day limit on how long a single instance of a workflow can run. In cases like these you will have to make design choices to compensate for what the end users are trying accomplish, and still stay under the limitations of Power Automate. This may include scheduled workflows that run on a periodic basis to perform actions when workflows hit a certain date, or you may have to create manual workflows to compensate for the processes that need to be reproduced. Ensuring that end user understand the limitations of the platform ahead of time can save everyone heartache when it’s time for the migration.

In Conclusion

While recreating workflows can be a huge pain, by mitigating the knowledge gaps around it for everyone involved at the beginning of every project, you can ensure greater success when migrating to the cloud. Please check out some of my other articles to take a deeper dive into the products and as always, please feel free to reach out to me at jo.karnes@centricconsulting.com