Enhance business process flows with branching
Updated: November 28, 2016
Applies To: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online
This topic shows how to create conditional branches in business process flows using Dynamics CRM. For information on creating a business process flow in Dynamics 365, see Help & Training: Create a business process flow.
Business process flows guide you through various stages of sales, marketing, or service processes toward completion. In simple cases, a linear business process flow is a good option. However, in more complex scenarios, you can enhance a business process flow with branching. If you have the create permissions on business process flows, you’ll be able create business process flow with multiple branches by using the If-Else logic. The branching condition can be formed of multiple logical expressions that use a combination of AND or OR operators. The branch selection is done automatically, in real time, based on rules defined during the process definition. For example, in selling cars, you can configure a single business process flow, which after a common qualification stage splits into two separate branches on the basis of a rule (Does the customer prefer a new car or pre-owned car, is their budget above or below $20,000, and so on. ), one branch, for selling new cars and another branch, for selling pre-owned cars.
The following diagram shows a business process flow with branches.
Take notice of the following information when you design the business process flow with the branches:
A process can span across a maximum of 5 unique entities.
You can use a maximum of 30 stages per process and a maximum of 30 steps per stage.
Each branch can be no more that 5 levels deep.
Branching rule must be based on the steps in the stage that immediately precedes it.
You can combine multiple conditions in a rule by using the AND operator or the OR operator, but not both operators.
An entity used in the process can be revisited multiple times (multiple closed entity loops).
You can go back to the previous stage regardless of an entity type. For example, if the active stage is Deliver Quote on a quote record, you can move the active stage back to the Propose stage on an opportunity record. In another example, suppose you’re currently in the Present Proposal stage in your process flow: Qualify Lead > Identify Needs > Create Proposal > Present Proposal > Close. If the proposal presented to the customer requires more research to identify customer needs, you can simply select the Identify Needs stage of your process and choose Set Active.
When you define a process flow, you can optionally select an entity relationship. This relationship must a 1:N (One-to-Many) entity relationship.
Only one active process per a record is possible.
A process name is not exposed to workflow conditions.
The stages can be reordered using the MOVE UP or MOVE DOWN arrows within the branch. The stages can’t be moved from one branch to other branches.
When merging branches, all peer branches must merge to a single stage.
The peer branches must all either merge to a single stage, or each peer branch must end the process. A peer branch can’t merge with other branches and at the same time end the process.
Let’s look at the example of the business process flow with two branches, for selling new and pre-owned cars.
First, we’ll create a new process named Car Sales Process.
Go to Settings > Processes.
Specify the Category as Business Process Flow and for the primary Entity choose Lead.
Add the first stage to the process called Qualify and add steps Purchase Time frame and Car Preference.
After the common Qualify stage, we split the process into to two separate branches, by using the If-Else clause.
If the Car preference = New, the process branches out to the New Car Sales stage, otherwise, it jumps to the Pre-Owned Car Sales stage, in the second branch, as shown below.
After completing all the steps in the New Car Sales stage or Pre-Owned Car Sales stage, the process returns back to the main flow, with the Deliver Quote stage.
Consider a business process flow with branches for processing a loan request at a bank, as shown below. The custom entities used in the stages are shown in parenthesis.
In this scenario, the bank loan officer needs access to the Request record, but she shouldn’t have any visibility into the investigation of the request. At first glance, it looks that we can easily do this by assigning the loan officer a security role that specifies no access to the Investigation entity. But, let’s look at the example in more detail and see if this is really true. Let’s say that a customer puts in the loan request for over $60,000 to the bank. The loan officer reviews the request in the first stage. If the branching rule that checks if the amount owed to the bank will exceed $50,000 is satisfied, the next stage in the process is to investigate if the request is fraudulent. If it’s determined that this is indeed a case of fraud, the process moves on to taking a legal action against the requestor. The loan officer shouldn’t have visibility into the two investigative stages as she doesn’t have access to the Investigation entity. However, if the loan officer opens the Request record, she would be able to see the entire end-to-end process. Not only will she be able to see the fraud investigation stage, but she’ll also be able to identify the outcome of the investigation by having been able to see the Legal Action stage in the process. Also, she’ll be able to preview the steps in the investigative stages by choosing the stage. While she won’t be able to see the data or the step completion status, she’ll be able to identify the potential actions that were taken against the submitter of the request during the investigation and legal action stages. In this process flow, the loan officer will be able to see the Fraud Investigation and Legal Action stages, which constitutes an improper information disclosure. We recommend paying special attention to the information that may become disclosed due to branching. In our example, split the process into two separate processes, one for the request processing and another one for the fraud investigation, to prevent the information disclosure. The process for the loan officer will look like this:
The process for the investigation will be self-contained and include the following stages:
You will need to provide a workflow to synchronize the Approve/Deny decision from the Investigation record to the Request record.
© 2016 Microsoft. All rights reserved. Copyright