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.
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.
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.
- Search by service when you build flows and other new features
- Microsoft Flow – Improve your switches
- Microsoft Flow – Large switches 25+ options
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.
Don't forget to subscribe to my YouTube channel.
Toodles.