Develop State Machine Workflow Using Power Automate In SharePoint Online

If sending notifications and building approval workflows are your business requirements, then look no further: Microsoft Flow could be your solution. Not only does it have a lot of flexibility in terms of integration with Power Platform, you get the MS Flow app on the Apple store and Google Play store from Microsoft.

Often business requirements are not sequential and may have multiple levels of approval. What will you do if the business needs are to bring the flow back to the prior step or dynamic steps? A standard sequential workflow isn’t going to support that process. Ah!

This is where the State Machine design comes into play.

What is Power Automate?

Microsoft describes Power Automate as “a unified platform with API- and UI-based automation for enterprise customers”, which is designed to cater to the full spectrum of users from technical to business. It works beyond just the Microsoft ecosystem, by connecting to apps and services like Salesforce, Box, Slack, Twitter, and many others. Power Automate was previously called MS Flow or Microsoft Flow, we will use both names in the article. Why the name change? Microsoft introduced Power Platform; i.e. Power Apps, Power Automate (MS Flow) and Power BI as a platform service to build Input forms using PowerApps, sending notifications and approvals through Power Automate and reporting through Power BI, thus offering a complete package.

Microsoft Flow does not provide a native way to build state machine workflow as of now, and the product is continually evolving. In order to create a state machine, here is the workaround.

Welcome to the State Machine Controller pattern.

Let’s take the following business case (see the next picture), a user submits a request in Web Application portal.

Level 1: The request will be approved by a group of users called “Level 1 Approval”
Level 2: If approved the request will be validated by a group of users called "Level 2 Approval"
Level 3: If approved the request will be validated by a group of users called “Level 3 Approval”
Level 4: If approved the Request will be validated by the "Level 4 Approval" and the Final document will be available to the Clients

If rejected at any level the request approval will go back to the previous level

Develop State Machine Workflow Using Power Automate In SharePoint Online

Setting Up a State Machine Template

Power Automate offers a template that supports the concept of a State Machine. A State Machine provides the ability to model your workflow in an event-driven manner. Power Automate accomplishes this by wrapping a Switch Statement inside of a Do Until. The Switch statement lets you transition from one Case to another until a certain condition is met, which will exit the Do Until. Whenever a process requires several levels of approval or dynamic pathways, you’re going to want to build a State Machine.

In order to configure the Do Until, you must first create a variable to use for the escape value. Below you can see that the Do Until will continue to run until the “Status” variable is “Completed.”

Also, note the Timeout value for the Do Until action. The default value is PT1H (1 Hour), which is 1 hour. Update this as necessary to support your process. The maximum value is P30D (30 Days) or PT720H (Day Converted to hours) (30 days).

Each level can potentially need more than 30 days to complete, but that is the easy part, we split the flow in several sub approval flows and after 29 days we restart the sub approval flow: there is no other technical solution, no discussion here.

Step 1

Step 2

The next step is to set up the Switch. The Switch works by executing the Case where the Switch’s “On” variable is equal to a Case value. In this Flow, we’re using the Status variable. By updating the Status variable to another Case value, you can bounce between Cases until the Status is Completed and the Do Until exits.

In our example, the Flow State Machine template design includes three levels of approval. With the Status variable initialized to “Level 1,” the Switch statement will start with the Level 1 Case. In the Level 1 Case, we will assign an approval task to the Level 1 Segment Tech Leader Approval. If the Level 1 Segment Tech Leader approves, it advances to Level 2.

At Level 2, we start to realize the power of the State Machine. Below is the logic for the Level 2 approval where we send an approval request to the Level 2 Approval. Based on the Response from that approval, that user can either Approve - which will update the Status to “Level 3,” sending the Flow to Level 3 -or Reject, updating the Status to “Level 1” and sending the Flow back to Level 1.

There are two benefits to using the Switch statement. First, there’s no limit to the number of Cases in a Switch (except for the Flow limit of 250 Actions in one Flow). Secondly, if there is no matching Case value, a Default Case will execute. With no limit to the number of Cases in your Switch, you can support a wide array of business processes with any number of approval layers. Additionally, the Default Case will capture any unintended states and can easily send an email to the Flow Admin to notify them of the issue.

Flow Limitations

A few Microsoft limitations do need to be taken into consideration, especially when using the State Machine template.

The first limitation to keep in mind is the one mentioned above - 250 actions in one Flow.
Flows that need more than 250 actions will need to implement nested workflows.
Secondly, Microsoft Flows cannot exceed 30 days. After 30 days, any pending steps will time-out; timed-out approvals are removed from the approvals center.
A user who tries to approve a timed-out request receives an error message.
This becomes an issue if the flow you’re building is supporting a process that naturally takes longer than 30 days.
In this case, you may need to break the process up into multiple flows. However, the goal with implementing Flow is to reduce the time between decisions and help get more done in less time.