Ninja List: The great migration of SharePoint Workflow to Power Automate
/
Hello, I’m John Liu, #FlowNinja
I am both MVP in Office App and Services (SharePoint) and Power Platform (Flow), I’ve been writing tools to help (4000+ in over 3500 tenants) makers manage and maintain their flows for the last two years. As a bonus, I also grok Power Platform licensing.
The announcement that SharePoint 2010 Workflows will be terminated on SharePoint Online is one that I’ve been planning for, even before Microsoft announced they would deprecate the workflow engine.
SharePoint 2010 and 2013 workflow engines are based on Windows Workflow Foundation. That team doesn’t exist. There’s no WF in .NET. Not to mention that WF is not an engine that’s designed for the cloud era - it runs on heavy machines, serialized through databases. It doesn’t auto-scale, or handle webhooks or does anything async. It’s an pre-cloud relic that doesn’t know how to get access to unlimited serverless compute.
But yet, putting aside my own criticisms of the old workflow engine, those workflows are still extremely business critical. So the Office team has been shouldering the maintenance of those workflows - while the world moves on to a cross services and cross platform solution built on Logic Apps and Power Automate.
I didn’t think we were ready yet to make the move in 2020. But we have to draw the deadline somewhere, so, let’s start by scanning and figuring out what is next.
This is my master ninja list of resources.
This is a highly curated list. I’ll be updating this until there are no more SharePoint 2010 and 2013 workflows.
Microsoft’s announcement
SharePoint PnP team’s modernization scanner
https://docs.microsoft.com/en-us/sharepoint/dev/transform/modernize-scanner
SharePoint 2010 Workflows - August 1 (off on new SharePoint Online tenants) November 1 (off for all tenants)
SharePoint 2013 Workflows - Already deprecated, future termination expected.
Microsoft Official Guidance
Community Resources
Todd Klindt
Sympraxians
SharePoint PnP
The main plan
Scan
Don’t panic.
Run the migration scanner and work out how many workflows you actually have. Then narrow it down to what are actually business critical.
I recommend the original SharePoint PnP Video explaining the technical parts of the modernization scanner. This also covers the InfoPath form scanning.
Todd Klindt in a follow up blog post talks about scanning the workflow history list in each site to determine if a flow has been running recently. This would help determining if an workflow is old and is it even being used.
Migrate
Re-write SharePoint Designer Workflow as Power Automate
Will need to connect to existing workflow via SharePoint Designer
In most cases, old SharePoint Designer Workflows run on change of a list item - these can be replaced with Flow’s Item Modified trigger or File Modified trigger.
If you have SharePoint Designer Site Workflows, or list workflows that have a Start Workflow dialog, then these need to be replaced with “SharePoint For Selected Item Trigger” in Flow
If you need to replace the out of box “Request Sign Off” or “Content Approval” workflows which both have Power Automate replacements, see Shane Young’s video
https://www.youtube.com/watch?v=RAADqTG2EZMYou may want to reuse workflow functionality, there are a few ways to go about with this:
Use HTTP to call child Flows (this is a premium feature)
You can use Solutions which helps with creating Parent Flow and Child Flow, but Solutions doesn’t help with multiple sites, so this isn’t a perfect case.
You can use Power Studio’s migrate to help you copy and manage deployment of a template flow across dozens and hundreds of SharePoint sites.
Power Studio’s Clipboard feature can be used to save snippets and re-use them with Flow designer’s copy and paste clipboard.
Power Studio’s Edit JSON feature can be used to rapidly clone an existing flow, and then modify it further (advanced user).
Monitor
Flow’s run history is only stored for 28 days
You can write a flow history to a separate list within your Flow to keep track of crucial flow run metadata
You may want to consider using Trigger Conditions which will help you ignore trigger events and make flow’s run history more manageable.
You can use Power Studio’s Run History to help you pinpoint which run you want to review, or even resubmit.
You can also use Power Clarity which provides continuous flow run monitoring and error notification.
Power Clarity gives reports of which Flows are running on what SharePoint sites.
The Pain Points
Not all actions have a direct replacement, but most of them are available, and the few that aren’t - we can get by with Send HTTP to SharePoint
Set permissions
There is a SharePoint action to grant permissions directly, or remove them
But if you want to assign permission roles, Chaks has these tweets:
Document Set actions
The story is improving and most actions with Folders can handle document sets. But we can also use Send HTTP to SharePoint as workaround.
https://twitter.com/johnnliu/status/992767564253089792
Impersonation
Automated Flow always runs as the maker, or rather, as the connection used in the Flow
Send HTTP to SharePoint can update SharePoint list items’ modified user and modified time.
When using Approvals - we can set the ‘Requester’ field of the approval, so the emails will still be sent from service user account, but the Approval Card says “approval requested by {current user}”
Instant Flow (For Selected Trigger) has the option of running as the current user.
Flow run time limitations
Power Automate - 30 days
Logic Apps with Integration Account - up to 1 year
Workarounds by changing logic to a recurrence trigger, and don’t design flows that will run forever.
Flows can re-trigger itself as we near 30 days to restart a new run.
No triggers that perform “If field A changed” - this can be done with Send HTTP to SharePoint and reading version history
Microsoft has mentioned they are working on an out of box action they hope to be ready before November - there may not be enough time, so you need to decide whether to wait or use Send HTTP to SharePoint first.
Update: Chaks has released this new action on the preview environment.
If you want Flow to run faster in lists - you may want to be familiar with using CAML to execute group-by, this let us work with list data in bulk quickly.
Right now, a user can have a maximum of 600 flows.
You can make more in Solution.
ALM
ALM are done via Solutions - Solutions in the default environment is standard.
Power Clarity can help with ALM if you don’t want to use Solutions - but you’ll need to contact me and get this moved up the roadmap.
Flow Versioning
Unlike Power Apps, Flow doesn’t have versioning.
Use Solutions - versioning at the solution or ALM level.
Write a Flow to backup your own flows (to SharePoint or VSTS)
Writing a JSON back into your Flow is a bit more trickier. I built a lot of the tricks and safeguards into Power Studio’s Edit JSON capability, so I recommend using that to restore to an earlier version.
Grouping
Imagine having to build hundreds of flows across all the sites into Flow designer - you will not be able to find your flows quick enough. So there’s a grouping or organizing problem.
Microsoft says use Solutions to group your flows
Flow Studio allows us to use #tags to quickly sort and filter your flows (any flows can have one or many tags, so they can belong to one or many groups).
At a very minimum, choose a flow naming convention so at least they can filter correctly. (But beyond 50 and when paging starts you’ll have issues).
The Gaps
No actions that perform “Wait until a field changed to X”.
Licensing
Automated Flows run as the maker - if the Flow needs premium connections, then that is either 1 P2 license for that maker - this is cheaper
If you need a lot of capacity, you can also consider the Per-Flow planScheduled flows are Automated Flows
HTTP Request (service flows) are Automated Flows
Instant Flows run as the current user - so if an instant flow needs premium connections - then that is best covered with the Per-Flow plan.
For Selected Item / File are Instant Flows
Flow Button are Instant Flows
A Flow called from Power Apps is covered by the Power App’s license. So if the flow needs premium, then the Power Apps needs premium, but the flow doesn’t need an extra flow-premium.
Power Apps Trigger are this category - they are instant flows, but are covered by Power Apps license.
Flows are no longer calculated by “Runs” or “pooled runs” - this was removed a while ago. There are no longer any ‘run limits’. But instead, there are service limits relating to number of API calls. Standard and Premium tiers have different API call quotas per day. Flow action can fail if you have run out of number of API calls in that period.
This may affect you if you are using “service user accounts” to run your flows - I recommend the easiest way is to plan and assign P2 to these “service user accounts”.
For very high volume Flow runs that are critical and can’t be filtered via trigger conditions, consider using Logic Apps and bring your own Integration Account ($$).
Updates (2020-09-17)
Let me know if I missed anything
Reach out, this is an ever updating list. We will add more resources - both our own and those from the community. Our goals here is to align with yours and Microsoft’s:
Make sure your business process workflows continues moving forward.
Teach and create patterns to help you make your own flows, and make them better.
Build tools that will help you do more, faster, if you don’t have the time.
