Wouldn’t it be cool if we can automatically change the Stage of the Business Process Flow once we get our Approval? It will be especially great if we can do so based on the Approval outcome! In this blogpost I will finish up my posts about Approvals by automatically changing the Business Process Flow to the next stage based on the outcome of the Approval.
This blog is part of a series about guiding users and teams through their work. This post is about Approval Flows inside Business Process Flows. Click here for an overview of all related post regarding Approvals inside your Business Process Flow. I also added a sample solution you can import in your own development environment so you can see the entire concept in action!
Keeping people in their flow of work by utilizing Asynchronous work or asynchronous processes is one of the key benefits for Business Process Flows. I have written down my thoughts on this subject here. Find out what asynchronous work is, how Business Process Flow can help and more advanced scenario’s.
Expanding the Case Business Process Flow
We are currently still working a Case of a broken screen, see this post for more details. We are dealing with a loyal customer, so we asked Approval of our manager to immediately replace the screen. He either gives Approval to do so, or we does not. Based on the outcome however, we need to take different actions. If our manager allows us to replace the screen, we will need to ask our warehouse department to pick the order and send it. If our manager disagrees with our assessment we will call and ask our customer if they would like to come in and let us repair the screen.
So that are 2 different outcomes with different actions we need to take. We can model that flow inside the Business Process Flow by using a condition. Inside the condition we use the result of the Approval. In our example we choose “Equals Approved”. Keep in mind that the field you want to use in the condition should also be in the previous stage as a field. After which the Business Process Flow splits in 2 branches and we can add different stages to each branch.
Anatomy of a Process
Before we go into the specifics of how we going to achieve automatically changing the state, I first want to explain what happens under the Dataverse hood. This will give some background information when we continue with our Cloud Flow. A simplified data-model can be found in the image below.
If you create a Business Process Flow a new table is created inside Dataverse. In my case this is the Case BPF. Every new instance or initiated process will add a new record to this table. This table contains the active stage and the traversed path. This traversed path contains all the stages the process has went through, including any backward steps in the flow.
The meta data of the Business Process Flow resides in the Process table (logical name is workflow). This table has a collection of different processes inside it, but if you filter it with category 4 you will get the Business Process Flows. The Stage name, Data Steps, Flow Steps and Action Steps are stored in the table Process Stage. Combine the two tables and this is what you see on the screen when you are customizing your Business Process Flow.
Expand our Approval Flow
As we want to update our process stage based on the outcome of the Approval we need to update the Approval Flow. First we initialize a variable called BPFNewStageId. This will for now be a placeholder, but it will eventually contain the Id of the Stage corresponding to the outcome of the Approval.
Second we get some extra information from the Business Process Flow record we are working on. We will need the Active Stage Id and the Traversed Path later on to correctly update the Traversed Path.
Now let me first give you an overview of the actions we are adding.
Based on the decision of our manager we either get approval or we do not. Corresponding stages are added to the Business Process Flow. Now we need to retrieve these stages. We query the Process Stages table and we filter on the Stage Name which equals ‘Approval given’. Of course on the rejected side we search for ‘Approval Rejected’ instead. We also filter on the Process Id. This Process Id we get from the “When a flow step is run from a business process flow” trigger. Please note that you need to query the ProcessId field like this: “_processid_value”. This is because of the OData notation from the web api.
We store the output of the retrieval of the Process Stage into the variable we initialized previously. This is so we do not have to use two duplicate actions to update the stage.
Because the List Items action can return multiple records, we grab the first of the outputs with an expression.
Update the BPF stage record of the process
Now that we know what stage we want to put our Process into we can update the “Case bpf” record. For this we choose the Update Record action from Dataverse. The Row ID is from the “When a flow step is run from a business process flow” trigger. We update the Active Stage column with the variable BPFNewStageId we filled earlier. To do se we use the OData notation: “/processstages(BPFNewStageId)”. Processstages is the plural name of the Process Stage table.
You also need to update the Traversed Path to reflect the step we just made. We do this by adding the New Stage to the Traversed Path we retrieved earlier. I use the expression concat with which I combine 3 strings. The Traversed Path, a comma and the new stage
concat(outputs('Get_current_BPF_record')?['body/traversedpath'], ',', variables('BPFNewStageId'))
And that will do it! This will update the Business Process Flow Stage depending on the Approval outcome! See the (somewhat longer) gif below to see the end result.
And with this epic functionality I conclude the Approval Stage of my exploration. I really enjoy building these kinds of Flows inside a Business Process Flow as this immediately helps the user do their work.