One of the newest additions to Dynamics CRM 2013 are the Business Process Flows (BPF).
From an initial view you may be forgiven for thinking that they’re a straight forward replacement for the 2011 Ribbon Bar. Not so! The Ribbon Bar has been replaced by a Command Bar, which will contain far fewer buttons on it. The Business Process Flows will actually negate the need for some custom Ribbon Bar buttons, but it has much more purpose than just that …
So, what are they?
A process defines the steps that are taken to reach an objective from a start position. There can sometimes be many routes through a process to reach the end objective. It is this concept that is modelled in 2013 Business Process Flows.
Let’s look at an example.
CRM 2013 comes with a few pre-defined Process Flows. In order to see where they are defined, navigate to Settings -> Processes -> Business Process Flows.
As you can see, you define and edit your Business Process Flows in the Processes section, as they are a new type of Process.
Let’s take a look at the Phone to Case Process.
This is the default BPF that is showed on the Case screen, as below:
Let’s create our own BPF using the Phone to Case Process as a starter.
To do this, open up the Phone to Case Process and click the “Save As” button at the top of the screen. This will create a copy of the process called “Phone to Case Process (Copy)”.
Let’s change the name of this Process, by clicking the Expand/Collapse button in the top right hand corner of the screen. We’ll call our new Process, “Incident Logging”:
Now, BPF’s are grouped in to sections called Stages:
We currently have 3 stages defined: 1. Identify, 2. Research and 3.Resolve.
Let’s add a new Stage in to the process. Simply click on the orange plus image next to the word Stages and then type in “INFORM” as the Stage Name. Click on the Move Up arrow to move our new Stage so that it occurs before the Resolve Stage. Your process should now look like the following:
Next you can define a Stage Category. These are pre-defined in CRM2013 [CAN THEY BE EDITED?]. Let’s select “RESOLVE” as the Category.
Now comes the important bit as this is where we can define the Steps that must be taken to complete this stage of the Process.
Click on where it says “New Step”. We can now give our new Step a name. Note that this is a free text description and should indicate the purpose of the Step. For our example, type in “Email Customer”.
We must then associate our Step with a Field. In this particular case, select “Activities Complete”. This is a generic option that will present the user with a Tick box to indicate if they have completed the action.
Finally, let’s tick the Required box as this will ensure that the User must have ticked the box to complete this Step before they can progress to the next Step/Stage in the process.
Your process will now look like this:
Have a go at adding another Step to our Stage as per the screenshot below:
This will allow the service desk analyst to capture the KB Article as part of the step.
Great! So we’ve defined our BPF yet there’s a couple more things we need to do in order to get it live.
First of all, we must set the Order Process Flow. This dictates which BPF is used as default for a given entity if there are multiple flows. Click on the button at the top of the screen and move our new process to the top of the list:
Next we need to enable the relevant Security Roles. You can restrict your BPF’s to be available only to selected Roles if required. For our example, let’s open it up to everybody:
Finally, just like a Workflow, we need to Activate the BPF to make it live. So, go ahead and click on the Activate button at the top of the screen.
Ok. Let’s go and see our BPF in action!
Navigate to the Service -> Cases section and create a new Case.
You should see our new BPF at the top of the screen:
Click on the INFORM stage and you will see the two stages that we defined. Have a look at how you can toggle the Email Customer stage and select a KB Article to link to the Identify KB Article stage.
Business Process Flow’s are a versatile and structured way to prescribe desired routes to meet an objective. They can span multiple entities (as long as they are related), including custom entities. They are also a very useful way to help train staff to follow a particular route although they should not be considered a replacement for Dialogs as they still have a clear use.