Back in early 2018, a customer asked for a recommendation to replace their SharePoint 2010 OOTB document approval workflows with a more modern approach.
.We were in the planning phase to migrate their SharePoint Online but classic DMS to Modern, so one
core part of the solution were the approval workflows.
The customer is a international startup in the medical sector, engineering and developing surgery robots. A crucial part to meet the international (Europe, USA, Asia) regulations is document versioning, approval and tracking in all it's beauty.
I said yes, we can do that very fast and cost efficient. Today, I think different!
It turned out to be one of my best learing pices and I want to share some of my experiences with you in this blogpost on the topic of "SharePoint document approvals with Flow."
This was my first real world Flow project with heavy SharePoint document focus. I'm doing Flow basically since it exists. But used it more as a middlewear to support and connect end-to-end business processes or connect hybrid data from backend systems to the cloud with on-prem data gateway.
I played quite a bit with AzureCognitiveServices and the integration between Flow and PowerApps for our SPSEvents session "The rise of the Citizen Developer". Oh not to forget that I also integrated BlockchainProof as a service (BaaS) into Flow with a custom connector.
In another project, I had the chance to build a e-mail/sms message notification queue using Azure storage tables and storage queues in Flow. So I had some basic experience and thought I knew what I was selling.
As with all technologies, we need to be wise, when choosing Flow or when it's maybe better to invest in more advanced application builder platforms like Skybow.
With customer connectors you can "glue" everything which provides a web API into your Office365 environment and make data actionable in a standardized way.
And why ist that so important? Data integration and availability are core pillars of a successful digital transformation. Most of your processes run on the company's core data and to make use of the cloud toolstack data needs to be integrated first to unlock it's value. Without data, or just with newly and cloud created data, you will end up in a data graveyard between the two worlds. CDM (Common Data Model) can be an answer here. It's another example of how easy we can integrate, structure and make available core data to Flow for CRUD operations.
From a citizen development perspective, Flow ist a wonderful tool to simply "get things done" and drive business efficiency in the digital transformation journey.
I'm seeing various customers just building Flows to automate repeating tasks like copy files from A to B, updating list data or keep track of different kind of requests or form processing. "Let's build a Flow for that" is becoming a scentence I'm hearing more often from our customers, even Switzerland is handling digital change sometimes slower than others.
With the "Microsoft Power plattform" and the strengthening of Microsoft ERP & CRM strategy, Flow will become more and more relevant while maybe evolving to something even bigger.
Customer usecase
So, now let's look at our customer usecase. My goal is to give you as much information as possible on the implementation steps, the core concepts of the solution and the overall solution, so you can avoid some traps and get value out of my experiences, which I had to pay myself for ;-)
In the past, the customer was using SharePoint2010 OOTB approval workflows. Nothing was customized in SPD. Workflow was just bound to library and basic configuration was set. Users initialized the workflow manually and defined the workflow initialization settings like approvers, type of approval, due date, etc. and started the workflow. So each workflow had a individual run context and was run on the pretty old but still fancy SharePoint2010 workflow engine on SharePointOnline.
Users didn't like the style of the quite cryptic e-mail notifications, but loved the flexibility of the OOTB functionality. If to look a bit deeper under the hood, this thing was quite powerful and more expensive 3rd party solutions weren't always needed. The engine could be extended pretty easily with managed code and custom actions, to integrate other systems and services.
Things should actually be easier nowadays, but sometimes new and different complexity is hitting us hard
As we arrived in the "modern" episode of it technology where all is decentralized, everything became a service and is talking to everything, client side code owns the world and data is structured and interacted within a Graph.
Key requirements
Some of the requirements of an enterprise level document approval process, as it could be similar in many enterprises.
The Flow insiders know, that this list contains a lot of challenges and the main challenge is to connect all the individual ingridients to one final pie:
Parallel and serial approval task flow
Dynamic number of approvers
Approval due date
Automated reminder e-mail based on approval date
Approval escalation/timeout when no response
Centralized and "immutable" approval log
SharePoint integrated via Flow launch panel
Advanced error handling with notification to initiator
Topics
Current limitations
Some important facts to be aware of, when building with Microsoft Flow:
Max 30 days flow run duration, Log history > Should be extended soon, Logic Apps has 90 already
Task reassignement
Missing state machine pattern
File locking
Credits
My Flow knowledge and passion is hardly influenced by the following community members:
Serge Luca, Ahmad Najar / Inspiration on Flow patterns, tips and tricks
Jussi Mori / Connector of dots, ommunity mentor of all times
John Levesque / Late night motivational conversations ;-)