Thanks for printing! Don't forget to come back to Intellinet for fresh articles!
SharePoint Workflow & InfoPath End of Life: 7 Tips to Make Modernizing Less Scary
For the thousands of enterprises out there still relying on SharePoint
2010 and 2013 Workflows to manage complex business process, there simply wasn't
enough time between Microsoft's
announcement last July and the actual retirement/depreciation date in
November to properly redesign and rebuild solutions.Many companies using InfoPath as part of the
solution have found the project even more daunting.This change in service also affected a lot of
unsuspecting customers using basic SharePoint approvals and other
out-of-the-box workflow solutions, who did not even realize they were using
WF2010. As a result, many companies
found themselves dealing with broken workflow solutions scrambling to produce a
last-minute strategy to recover.To make
matters worse, a lot of these solutions were built many years ago, so the
original architect, BA, designer, developer, and process SME's have since moved
on and taken their tribal knowledge with them.
As a side note, I should mention that this applies only to
SharePoint Online.SharePoint
on-premises is a different story (for the near future).But those of you who are running WF2010 on
prem, and planning to migrate sites to the cloud, will need to address this
issue before migrating.
What's the Quick Fix?
I hate to break the bad news - there is no easy fix.If you are reading this, then you probably realize
that WF + InfoPath solutions are essentially custom software solutions.Perhaps some of the first to be considered
'no-code' or 'low-code', but still custom software solutions, nonetheless.Many of which are managing extremely
complicated processes with lots of branching, decision trees, automation,
business logic, etc. baked in.And,
being SharePoint solutions, these processes typically carry some sort of
payload, such as documents, list items (data), electronic (XML) forms, and so
on.Not to mention unique item-level permissions!As such, there are typically many facets to these
solutions, in addition to the technical aspects, that can make these projects very
challenging.And, no, unfortunately there
is no migration tool that will automatically upgrade WF2010/2013 solutions to
Power Platform, nor InfoPath to Power Apps.
For that reason, we wanted to provide some helpful tips to
avoid the hidden traps you may encounter, and hopefully save you some hardship
along the way.Naturally, as a lifelong
IT professional and drinker of the Microsoft cool aid, I believe the 'obvious'
approach is to migrate SharePoint Designer workflows to Power Automate/Flow,
and InfoPath to Power Apps.Therefore,
this post is based on that approach.
1. Scan your environment
It is important to begin by scanning your environment holistically,
to understand the width and breadth of the technical debt.The free Microsoft tool to do this is called
the SharePoint
Modernization Scanner, but it only works with SharePoint Online.If you are planning to migrate your tenant
from on-prem to online, the tool for scanning on-premises SharePoint farms is the SharePoint
Migration Assessment Tool.
The output from the tool will give you an excellent handle
on the amount of workflow and InfoPath you have in your environment, along with
some granular details (such as number of actions) that you can use to estimate
overall effort.See the Microsoft
reference documentation for details on the output for workflow
and InfoPath.
2. Understand your data options
There are many options available for the back-end of a Power
App but, if you are coming from an existing SharePoint solution, your basic
options will be SharePoint Document Libraries and SharePoint Lists, or you
could choose to move to the Microsoft Common Data Service (CDS a.k.a. Dataverse).
If you want to maintain the SharePoint look and feel of your
existing solution, have a lot of SharePoint documents involved in the process, or
if you're not ready for the CDS, then custom lists or document libraries are your
best bet.If your existing solution
leverages an XML document library, you will want to move towards a list or
document library and eliminate the XML library from your solution, as Power
Apps eliminates the need for XML-based forms.This can be more complicated than it sounds since XML forms often write some
of their fields to XML library columns while managing and maintaining other
fields only in the XML form itself.In
these scenarios, you will need to identify those XML-only fields and create new
list columns for each, for the new Power App to manage those data fields.
WARNING!A lot
of InfoPath solutions manage a very large number of data fields.Recently, we came across a project where one
of the InfoPath forms had over 300 fields.The form wrote approximately 175 of those 300 fields to the XML library
columns.However, over 150 of the fields
were stored and managed only within the XML document itself.This data was critical to the workflow
process.As you may have guessed, while creating
new columns to manage those fields we hit the limit of list columns in
SharePoint (actually, it's not a column limit but a max record size) and were
forced to create a second list to manage the overflow of columns.
If you are not married to the SharePoint UI for your
solution, the CDS is a very powerful cloud-based back-end.Think of it as SQL Server for business apps that
allows you to create tables with columns and relationships (formerly called entities,
fields, and relationships) without being a database developer.Power Apps built on CDS back-ends are called Model
Driven Apps.Be aware there are some licensing
considerations attached to the CDS, so make sure you understand how that will
impact your project.Going in this
direction will reduce, or maybe even eliminate, your dependency on SharePoint
since the back-end will no longer be based on a SharePoint list or library.This, of course, will have a big impact on
user experience as well.Make sure to
plan accordingly.
3. Eliminate the XML library
It is very common to break a software project like this into
phases.For WF and InfoPath projects in
particular, it might seem logical to attack the InfoPath to Power Apps piece in
phase 1, and then the Workflow to Flow workstream in phase 2.However, if you have an InfoPath solution
with an XML back-end, your workflow is probably implemented against the XML
library as well.If you are planning on
eliminating the XML library from your solution, then you will need to rebuild
your workflows at the same time.In this
scenario, it is possible to refactor all your 2010 workflow for the new list or
document library and leave the Flow development until phase 2.This approach might minimize effort on the
workflow workstream to allow more focus on the Power Apps workstream in phase
1.However, we have found it best to
implement Flow and Power Apps in one unified phase, such that you can cut over in
one release.
4.Allow time for Flow approvals POCs
If you are using WF2010 approvals, we find they are replaced
nicely by the Flow approval process.However,
there are some differences in the details that will require allotting additional
time for proof of concepts to get it right.Keep in mind, there is a user impact with the Flow-based approval
process.
5. Be aware of Flow history and timeouts
There are two major caveats to be aware of between Workflow
and Flow.First, Microsoft Flow is
limited to 28 days of history.Second, long
running Flows will timeout after 30 days.If you have the need for long term retention on WF history or long
running process (greater than 30-day approvals for example) be aware of this,
and make sure you plan for development time to refactor your process logic accordingly.
There are several tutorials online that
describe techniques to trap these timeout events and deal with it gracefully.
6. Realistically Plan for Migration/Cutover from the
XML Library
One of the more challenging facets of upgrading a live workflow
solution is cutting over to the new solution.Aside from dealing with in-process (running) workflow instances, if your
solution is eliminating an XML library, be aware there are some additional
complications.Be sure to plan for
migrating your XML library data to your new list or document library.This may seem straightforward but can prove
to be quite challenging.Not only will you
will need to move existing XML library column data into the new list (this is the
straightforward part), but if your InfoPath forms contain data elements that
are not written to XML library columns (like the scenario painted above), you
will need to write scripts to extract and move that data as well.
They key here is not to underestimate the amount of work
required.Testing is crucial,
extremely time consuming, and will impact the business users who are required
for comprehensive UAT.Plan accordingly.Since much of this is a manual effort, we
found that leveraging our hybrid team of onshore and offshore resources for
planning and execution can offer a high-velocity solution with minimal
downtime.
7. Explore the opportunity to innovate
While
the intent of this blog was to focus on a straight port, keep in mind that
these projects are a great opportunity to strategize with business
leaders.With Office 365, Power
Platform, and Azure it is amazing what you can accomplish with minimal effort
and a little creativity.If you are in
the process of eliminating legacy WF2010 and/or InfoPath from your technical
debt, this may be the perfect time to innovate and provide true digital transformation
for your business.