Business Process Flow (BPF) Automation – Concepts

The Business Process Flow Automation capability was introduced not long ago, when the BPF entity was introduced as part of Business Process Flows. The BPF entity itself has opened various possibilities to build powerful automation that were previously not possible via workflows and there are some powerful things that can be done outside the standard BPF designer. BPF automation can be used in conjunction with other automation to build a rich user experience in the Power Platform. The goal of this post is to equip you with necessary concepts involved in the automation of BPF so that you can use the tool of your choice to achieve the desired outcome.

Precisely, I will be discussing the following:

• Business Process Flows – A Quick Overview
• Automation Scenarios
• Triggers Available in the Designer
• BPF Entity
• Workflow on the BPF Entity
• Stage Transition Rules
• Wrap Up

Business Process Flows – A Quick Overview

If Business Process Flows is new to you, you can read about it here. However, to give you a quick recap, BPF provides you a guided experience where the users can follow a process consistently where you may apply the concept of stage gates by preventing users to proceed to the next stage unless they complete certain actions. The following screenshots show how it displays in the Unified Interface and how it is created using BPF Designer.

Automation Scenarios

Following are some of the examples where you can apply BPF automation.

• Update data record when a change happens to BPF
  • For example, automatically close the opportunity as won when process is finished
• Update BPF when a change happens to the data record
  • For example, automatically change the BPF stage (update BPF) when the underlying data record gets updated from Canvas App, Portal or even by an external system.
• Synchronise BPF Stages with external systems
  • For example, update BPF Stage from ‘Order’ to ‘Invoice’ when an external system completes order processing. This can be used in various integration scenarios where some processing is done externally and the external system notifies your application which should result in change of process stage.
• Manipulate PBF Stages in exceptional scenarios
  • For example, after data migration you have to set correct BPF stages on the migrated records

Triggers Available in the Designer

As you can see in the screenshot below, workflows can be triggered on the stage transition or when the status of the BPF changes i.e. BPF is Applied, Completed, Abandoned or Reactivated. When using workflows on the stage change, you can only use active on-demand workflows created for the same entity mapped the stage. When triggering global workflow, you can only use active, on-demand workflow created for the primary entity of the business process.

As you can notice, for the global workflow, the fact that the workflow can only be triggered for the primary entity introduces some limitations which can also be addressed by using other automation techniques discussed in the rest of the section.

BPF Entity

Imagine you have a Lead to Cash BPF with 5 stages and each stage is mapped to a different entity as shown below. When you save your BPF and activate it for the first time, behind the scenes a special entity gets created that corresponds to this newly created BPF. This is the entity that represents the BPF. Besides other standard fields such as Name, Created On, Stage, Status, Status Reason, Active Stage, Active Stage Started On and Traversed Path, it also creates lookup field to each of the data entity that is mapped to the stage.

Workflow on the BPF Entity

Just like you can create workflows on a regular data entity such as opportunity, you can also create workflows on the BPF entity such as Opportunity Sales Process entity that corresponds to the Opportunity Business Process Flow. Before looking at the workflow on BPF entity, let’s quickly revisit what happens when you create a workflow on a regular entity. You can see that in addition to other options you can trigger workflow when the fields in the opportunity entity change as highlighted below.

Now, when you create a workflow on the BPF entity, you can trigger the workflow in a similar way. Here is a quick comparison between a normal workflow and workflow on BPF entity.

One important thing note is that the fields available to trigger the change event in case of BPF entity workflow are different depending on whether the workflow is a real time or background. When creating a real time workflow, the experience will be similar i.e. you can trigger the workflow just like any other entity where fields in the same entity change. However, when creating a background workflow on the BPF entity, you not only get the ability to trigger the workflow on change of BPF entity fields but also on any related entity which is related by M:1 relationship between BPF and other data entity. This is something that you cannot do in your normal workflows but obviously with the availability of MS Flows, you can achieve the same behaviour. I will leave it for some other post to compare Workflows and Flows when it comes to automating BPFs as I do have some learning from there also.

As you can see in the following illustration, background workflow makes available another dropdown to select any (M:1) related entity to trigger the workflow on the BPF. This is a very cool functionality that allows you to listen to changes on the data record and take action on the applied BPF for example, change the Stage to Approved when approval field is set to Yes on the related data record. For performance reasons, this mechanism is not available for real time workflows.

Stage Transition Rules

Forward Transition – Single Stage

When it comes to stage transition, all you need to do is update the Active Stage field of the BPF instance. An important rule to remember is that you can only move one stage forward where the stage is in one of the valid paths in the BPF. In the following example, if you are are at stage S2 and want to automate your transition to the next stage, you can either transition to S3 or S6 but not to S4, S7, S5 or S8. If you ware wondering how to make multi-stage transition please continue reading.

Forward Transition – Multiple Stages

When it comes to multiple stage jumps, you can use the single stage rule and implement it as intermediate transitions to achieve your resultant multi-stage transition. In the following example, we cannot go from S2 to S5 directly i.e. a jump of 3 stages, instead we can implement 3 intermediate jumps of single stage to achieve the desired result i.e. from S2 to S3, S3 to S4 and finally S4 to S5.

Backward Transition

Backward transitions are quite flexible compared to the forward transition rule. However, before understanding this, I will briefly mention another important term called ‘Traversed Path‘ which is also stored in the BPF entity. Traversed Path is the path taken from the start of the BPF stage to reach the current stage. If you started from Stage S1 and moved to S2, S6 and S7, the traversed path will be S1-S2-S6-S7.

The rule for backward transition is that you can go back to any stage that is in the traversed path. You can find its illustration below.

Wrap Up

This post was mainly focused on the concepts and not really whether you should use MS Flow or classic workflows even though I explained some features specific to classic workflows. There are instances where you will find one approach better than the other and also when you have only a particular option to use because of your requirement. I will touch upon those elements some time in future. Understanding these concepts will help you come up with a potential solution to your automation requirement.

In my future posts, I will show some sample applications of how you can use these concepts in your implementations and solve real life challenges.