Branching

in the previous step, you learnt that each business process flow definition has a separate entity defined in the data model. In addition to adding stages to a business process flow, you can also add conditions to create branching.

These conditions are a simple decision tree based on the data from the stage immediately preceding it. For example, you may have a condition whereby opportunities with an estimated revenue greater than $100,000 have additional required steps in preparing the presentation, but all other stages are identical.

Here we see an example of branching in a business process flow modelled after a car purchasing process. Notice the ebb and flow of the process, the decision-making points that lead to branching, and the close at the end. If this were a business process flow that we’d implement, there would be more details, such as a branch for leasing and a branch for trading in an existing vehicle and a close as lost option.

Branches may be used as a simple decision point of where an additional stage is added for some records or where the process splits into two distinct processes. In more complex scenarios there may be multiple levels of branching, for example where answering yes to a condition starts a stage and answering no presents another condition.

This is helpful in scenarios where the process always starts the same way but may have very different needed steps based on the information that is uncovered. An example would be a customer service team that triages incoming cases. One case may need to handle a recalled product while another case may be related to a customer who is out of entitlement terms and needs to be routed to the sales team to purchase another support package before the issue can be resolved. This business process flow would start with the intake of the case and then have several unique branches after the nature of the case is determined.

Adding additional branches is where the limit of 30 stages per process can be helpful. A business process flow can have up to five levels of branching, although one to two levels is the most common.

When using branches, you must determine how the process will end. You can merge branches back into a single-stage or end the process on each individual branch. 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.

The following process would not work, the peer branches do not merge into a common stage:

This process below would work, as all peer branches merge into a common stage:

Be mindful of complex security environments where a user should not have visibility into all records in a given process. If one continuous process includes entities the user does not have permission to see, the user will still see the steps in the business process flow, and that may constitute improper information disclosure. In these situations, it is best to have separate processes instead of branching processes.