BUSINESS PROCESS FLOW – AUTOMATION OF BPF STAGE MOVEMENT

INTRODUCTION

Some business requirements involve BPF (business process flow) to be integral part of their case management (Service Module) or lead management (Sales module) or any custom entity they have developed. It is a beautiful visual representation for business users by viewing BPF and getting to know the stage in which a lead is in the sales process or the stage in which a case is during case management process.

Recently I got a business requirement to automatically move the BPF stage based on the case status. The business user or someone who is working on the case wont manually click the button to progress into next stage rather the BPF stage should automatically be moved to previous or next stage. This blog will enhance your knowledge on BPF and will help you to achieve any of your business requirements which aim at automating BPF stage movement.

BUSINESS PROCESS FLOW ARCHITECTURE IN DYNAMICS CRM

Ever wondered what is the architecture Microsoft has built behind the scenes of a BPF? Though Microsoft wont show all the processes and activities running behind scene, we have the privilege to be able to view atleast some of them.

In reality, when you try to create a BPF for any out of box or custom entity, in the backend a SQL table is created for that BPF. This can be confirmed by viewing the group of entities list in the default solution. The name of the newly created entity is same as the name of BPF.

Let us take the example of case entity. By default, every case entity has an out-of-box BPF named “Phone to case Process”. Screenshot attached.

It has 3 stages: Identity, Research and resolve. Based on your business model, you can put constraints on each stage which will force business users to meet those conditions before moving to next stage in the BPF. Similarly, we have 3 case status: In-Progress, researching and resolve. The business requirement I got is based on the case status, the BPF should automatically change its stage (without anyone manually clicking the next/previous stage button to move stages).

There are 2 ways of achieving this business requirement:

1. Java Script: Xrm.Page.data.process namespace provides events, methods and objects to interact with BPF  data in a form which might help us to achieve any business requirement related to BPF. Msdn link is:

https://msdn.microsoft.com/en-us/library/dn817878.aspx

Java script is not a good fit for my business requirement. Suppose a case is resolved automatically from a workflow or plugin and when I open the resolved case, the java script triggers and it captures the case status as resolved. So, it tries to move the BPF to resolved stage. Surprisingly, we will get a script error saying “Case is resolved. Please reopen it to make necessary changes” which implies after a case is resolved we cannot edit the BPF stage. Therefore we are handicapped from using java script to meet out requirement.

2.  The second solution is using a out of box workflow. This might surprise a lot of you how we can use workflow to automate BPF stage. Thanks to Microsoft team who have beautifully developed an architecture around BPF. For every BPF that we create in CRM, an entity will be created in the backend which is visible in default solution.  

Let us walk through some of the significant fields in the BPF entity for case record:

1. Incidentid : This is a lookup field on BPF record which will point to the parent case record.
2. Activestageid: This is a unique identifier of lookup to active stage of business process flow instance. This plays a very key role in my workflow. If I want to change the stage of BPF, I must change this lookup field to point to next/previous stage.
3. Activestagestartedon: This field captures the date & time when active stage is started on.
4. Completedon: This field captures data & time when the business process flow instance is completed on.
5. Duration: The field calculates time between started on & completed on which is used to find how much of time is spent on this stage.
6. Name: It is a single line of text field which contains the name of Business process flow.
7. Processid: This field is a lookup to the workflow (BPF) associated.
8. Traversedpath: This is a single line of text field which contains comma delimited string of process stage ids that represent visited stage of BPF instance.

Though we might not be using all the above fields to achieve our business requirement, it is always best to know about the capabilities that are possible using the BPF.

There is a 1:N relationship between case entity and Phone to case process entity. The child entity has a lookup field to parent incident entity. Since 1 case record can be associated with only 1 phone to case (BPF) record (as every case record created has only one BFP, there is only one record in the BPF entity that is associated with the case record), though it is a 1:N relationship we have created a lookup on case record which points to phone to case entity record.

The next step is whenever a new case record is created, a new record will simultaneously get created in phone to case entity with incidentid field pointing to the newly created case record. We have written a out of box workflow which will trigger on phone to case entity at process is applied step. Since incidentid lookup will already be filled with case record, we can update the custom lookup field on parent case record to instanceid (it is the GUID of the newly created BPF record). This workflow helps to establish 1:1 relationship between case record and related phone to case process record.

Once we have populated the lookup field on case record our job became easier. We have established a relationship between case record and BPF record. The next step is to develop another workflow which gets triggered on case status change and change the activestageid field to automatically move to next/previous stage.

From the above screenshot we are checking if the Active stage Id is In-progress, then move to next stage – Research and finally to Resolved stage. If our current stage is research then move to resolved stage when case status is resolved. Inside the BPF record, we are setting the active stage Id field to resolved.

One key point to keep in mind is we cannot jump from one stage to another stage. We have to progressively move each stage one by one to reach our destination stage or else it will throw an error.