Moving Dynamics CRM Business Process Flows with multiple Branches

Business Process Flows (BPFs) can be used to guide users through different phases to reach a desired outcome. BPFs make use of stages and steps, where stages are different phases in a process which users can complete one by one before moving on, and steps are fields within a stage which can be used to make sure users fill in the required amount of information before moving onto the next stage.

In a recent project we needed a Business Process Flow for a custom entity with few conditions.

The first condition being that this BPF would only become visible if a certain field on the form was populated, which I have already covered in a previous blog. The second was that the steps or fields in each of the stages be specific to the populated field. This ended up introducing a third condition of the stage in the BPF needing to be automatically moved to the next stage on create of the custom record. These remaining two conditions will be covered in this blog.

The second condition of using unique steps in each stage was achievable using an existing feature of BPF’s called branches. With branching I was able to specify which fields would be shown in each stage based on the value in a specific field as long as that specific field was in a previous stage.

An example of simple branching can be seen in the screenshots below, with ‘Player Position’ being the specific field. This led to the third condition being introduced with the addition of a base stage in the BPF, as a user would need to manually click to go to the next stage if they had entered a value into that specific field, which they should not have to do.

image thumb 1 Moving Dynamics CRM Business Process Flows with multiple Branches

One of the issues you’ll came across was when using the Xrm.Page.data.process function ‘moveNext()’, which is supposed to move the current active stage to whatever the next stage is. By attempting to call this onSave you’ll see that the moveNext call was not doing anything.

Also attempting to call this after save completed, using ‘save().then()’, while also cancelling the default save using the ‘preventDefault()’ method, showed nothing happening.

The best way is to refresh the page after the save had been completed.
 
A few important things to note are, that you should only do this when ‘getFormType()’ was equal to 1 (create), and when a global variable used to check if it was the first time saving the form was true, which would then get set to false after the first save. These were added to prevent any infinite save loops and to make sure that the refresh would only happen on create of a new record.

It is also important to note that ‘Xrm.Utility.openEntityForm()’ was used to refresh the page with the entity name and record id as this is supported.

Let’s block ads! (Why?)

Magnetism Solutions Dynamics CRM Blog