When a business process is documented, sending notifications and requesting approvals are Microsoft Flow’s1 bread and butter. But often, multiple levels of approvals are required. What do you do if a rejection needs to bring the flow back to the prior step? A standard sequential workflow isn’t going to support that process. This is where the State Machine design comes into play.
What is Microsoft Flow?: Microsoft Flow is a software solution that allows users to create and automate workflows in applications and services, with limited intervention from developers or programmers. It works beyond just the Microsoft ecosystem, by connecting to apps and services like Salesforce, Box, Slack, Twitter, and many others.
Setting Up a State Machine Template
Microsoft Flow 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. Microsoft Flow 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, which is 1 hour. Update this as necessary to support your process. The maximum value is PT720H (30 days).
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 manager. If the Level 1 manager 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 manager. 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.
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.
Export and Import
Microsoft Flow supports the ability to export a Flow as a .zip in order to move the Flow from one tenant to another in a straightforward manner. This accommodates a number of scenarios: from building a Flow in a demo tenant and moving to Production or building a Flow for a client in your own tenant before introducing it into their tenant. This is especially important for instances where the Flow modifies a SharePoint list item. You can’t afford to test this in production.
First, you will Export the Flow from development as a Package (.zip). The Export screen will ask for a Name and a Description for the Package. Once you click Export, the Flow will be packaged into the zip file and you will be prompted to save the file.
The next step is to Import the Flow into your target environment. Navigate to My Flows and Click “Import” near the top of the screen.
Here, you will upload the zip file you downloaded from the Export. To Import, you will need to review the Package Content. Now you have a choice: update an existing workflow or create a new one. Keep in mind, each Flow must have a unique name. Next, you’ll need to reconcile the Related Resources. This is accomplished by selecting credentials to use for the Connections used in the Flow (SharePoint, Outlook 365 Outlook, etc.). If you don’t have a connection defined that’s used in the Flow, you’ll be prompted to create one. After all the necessary information is collected, click “Import.” A few minutes after the Import is completed, the connection will appear in “My Flows.”
To use the new Flow in the target environment, the SharePoint URLs will need to be updated. The import will retain values from the source environment SharePoint URLs, so these will need to be updated to the target environment values. Finally, save your changes.
Tip: If you use the SharePoint Connector “For a selected SharePoint item” to start your Flow, the action will ask for Site URL and List Name. What Flow really wants is the List GUID. Updating the List Name value to a list or library ID will associate the Flow with that list or library.
Once saved, your new Flow will be available in the Flow menu for a selected item in your list (or library in SharePoint Online).
Bringing it all together
The current Microsoft template for a State Machine is built to be started when a document is created in SharePoint. Now that you understand how the State Machine works, you can recreate the State Machine design in a template of your own. When building your Flow, keep some of the limitations in mind as you design the process, and break up the workflow where necessary. Finally, take advantage of the ability to move the Flow between environments, so that when it gets to production, you’re introducing reliable automation and making a great impression on your users.
If you’re looking for help with any aspect of Microsoft’s business-process documentation , know that Anexinet has the expertise, knowledge and skilled staff to achieve your goals and ensure a successful outcome. Our mission is to help organizations provide the best digital experience possible for end users, so please don’t hesitate to reach out to us with any questions.