Benitez Here.: Automatically update the stage of a Business Process Flow with Flow

I have worked on Dynamics 365 for Portals projects and one of the things I get asked is how to reflect the lifecycle of an application back in the model-driven app. This is for the purpose of users who need to interact with the application to progress it for the ultimate goal of the application being approved. Naturally Business Process Flows come to mind because it's a visual aid to help users understand what is to be completed in each stage.

I wanted to see if it is possible to automatically update a Business Process Flow using Flow based on interactions by multiple types of end users. These would be end users of the portal and end users of the model-driven app. I put Flow to the test and it worked 😄 In this WTF episode I cover how to automatically update a Business Process Flow stage with the power of Flow.

Quick lesson on behind the scenes of Business Process Flows

For the folks in the community who have been around the Dynamics 365 circuit for a while, the method of retrieving and updating BPF fields within the record is deprecated.

For example Stage ID and Traversed Path will display as deprecated in the Application entity customization settings. Note: for some reason in https://web.powerapps.com the Stage ID was not displaying so my screenshot is from the classic solution editor.

The current supported method is to reference fields in the BPF entity that would have been created when your BPF was created. In my scenario I created a custom Application BPF and a custom BPF entity was also created. There are fields within this entity that will be used in my WTF Flow which are

Active Stage ID - this will contain the stage ID value of the Business Process Flow stage the application is currently in
Application - this is the lookup to the application record
Business Process Flow Instance ID - this is the ID of the record that will be used in a Flow action
Status
Status Reason
Traversed Path - this will contain the active stage IDs the Business Process Flow has gone through in its lifecycle

Use case

I am extending my Grant Application Management solution to replicate the real world of an organisation. I have previous vlogs and blogs that cover it.

In a nutshell

a grant application is submitted through the portal
an external reviewer is assigned to the application where they are required to approve or reject it through the portal
an internal reviewer also approves or rejects it within the model-driven app
until there are two approvals, the application will not be updated to Approved

To keep it simple and for demo purposes I have three stages in my custom Application Business Process Flow.

In Progress
Review
Approved

Here is the interactions of the end users that will trigger the Flow

When an application is submitted by an Applicant through the portal, the Business Process Flow stage of the application record should automatically move from the In Progress stage to the Review stage. This is so that anyone within the organisation can see that the Application is now in the Review stage.
When both the External Reviewer and Internal Reviewer has approved the Application, the Business Process Flow stage of the application record should automatically move from the Review to Approved stage.

This is a Business Process Flow that uses a single entity.

Let's Flow

1 - The trigger

The trigger will be when the status reason of the Application has been updated.

2 - Retrieving the Application Business Process Flow record

Since the supported method is to reference the fields in the Business Process Flow record, the List Records action is used to retrieve the Application BPF record associated to the Application.

The filter query is for the purpose of only returning the Application BPF record associated to the Application. If a filter query is not used then ALL Application BPF records will be returned.

3 - Parse JSON

To reference the properties returned in the JSON response from the List Record returned, the Parse JSON action will be used. In my expression I am use the first function which I covered briefly in my previous WTF episode.

4 - Compose action for the Review stage ID

To move the Business Process Flow from one stage to another, the stage ID needs to be captured in the traversed path field. I am using two compose actions to store the value of the stage IDs.

To identify the stage ID values of the Business Process Flow there is a Dynamics 365 API request which can be found in the docs.microsoft.com article.

In the API request you reference the Dynamics 365 organisation URL along with the ID of the business process flow record. The simplest way to grabbing the ID is to do it from the Business Process Flow record.

Once you execute it in a browser it will look something like this:

Copy and paste into Notepad++ and use the JSON viewer plugin so that the response can be easier to read for the Business Process Flow stage IDs.

The Review stage ID can now be referenced in the Compose action.

I decided to use two Compose actions because I don't know how to store the Dynamics 365 API request in a Flow action. If you know how to do this, feel free to blog and tweet to me so that I can check it out.

5 - Compose action for the Approved stage ID

This Compose action references the Approved stage ID.

6 - Initialize Variable action for the Switch action

If you have not used the Switch action before I recommend checking out the Flow blog and Pieter Vienstra's blog to learn about the Switch action. He has a couple of great blog posts on the Switch action.

The reason why I am using a Switch action is that there are multiple outcomes for the Application Business Process Flow based on the Application Status Reason. Using the Condition action would work too but it means that there will be a few branches and if you have a Business Process Flow with more than 3 stages, the Flow could look like a mess.

Using a Switch is just as effective and provides the desired output based on the Application Status Reason. A single field is defined in the Switch that will drive what should happen next in the Flow.

The Initialize Variable allows me to reference the Application Status Reason in my switch. I set the type to Integer as the Status Reason is an Option Set where each value in the Option Set is an integer.

7 - Switch it up

In the Switch action we reference the variable. Based on the value of the Status Reason a switch will be performed. The two cases can are defined as

If the Status Reason has been updated to Submitted the Business Process Flow record needs to be updated from In Progress to Review.
If the Status Reason has been updated to Approved the Business Process Flow record needs to be updated from Review to Approved.

7.1 - Moving to the Review stage

When the Status Reason equals Submitted, the CDS Update a record action will be used to automatically move the stage from In Progress to Review.

Entity

The entity referenced will be the Application BPF. Reminder that this is the entity that was automatically created when the custom business process flow was created.

Record Identifier

The Record Identifier will be the business process flow instance id from the Parse JSON action. This property uniquely identifies the business process flow record associated to the Application.

Traversed Path

The Traversed Path is a field as mentioned earlier that represents the lifecycle of the business process flow as it contains the stage IDs the Business Process Flow as gone through. The Traversed Path field value needs to be updated to include the stage ID of the current active stage it will be moved to. This is the Review stage.

To include the stage ID in the Traversed Path field the concat function is used in an expression. This allows the Review stage to be appended to the existing Traversed Path field value which can be derived from the Traversed Path property in the Parse JSON action.

The expression will be the following

concat(body('1.3_Parse_JSON')?['traversedpath'], ',',outputs('1.4_Review_Process_Stage_ID'))

Active Stage

This field value will be the earlier Compose action that references the Review stage ID.

Application

The final field to ensure you populate is the lookup that associates the Business Process Flow record to the Application. This is done through the Application ID from the trigger.

7.2 - Moving to the Approved stage

When the Status Reason equals Approved, the CDS Update a record action will be used to automatically move the stage from Review to In Progress.

Same definitions except for a couple

The same field definitions apply however there's two more that is required in the CDS Update a record action since the Approved stage is the final stage in the Business Process Flow. This is so that the final state of the Business Process Flow is correctly reflected to the end user in the model-driven app. For further information refer to the docs.microsoft.com article.

Status Reason - this will be set to Finished
Status - this will be set to Inactive

Flow in action

Time to run the Flow. When the Application has been submitted through the Portal, the Business Process Flow of the application record will automatically move from In Progress to Review.

When the Application has two approvals - one from the External Reviewer and the other from the Internal Reviewer, the Business Process Flow of the application record will automatically move from Review to Approved where the state will show as finished.

Summary

Based on different end user interactions whether it is through Dynamics 365 for Portals or within the model-driven app, the business process flow of a record can be automatically updated to progress from one stage to the other using the power of Flow.

Don't forget to subscribe to my YouTube channel.

Toodles.

Benitez Here.

Thursday, 9 May 2019

Automatically update the stage of a Business Process Flow with Flow