Branch Step

This introduction article will help administrators to configure the Branch Step within a workflow in TDAdmin for Ticketing applications. The user must have the administrator access in the desired ticketing application.

Overview

In workflows, a branch step allows administrators to manage variant paths in a process based on defined rules. When a workflow reaches the branch step, the branch selection is done automatically in real time. Then the selected step is executed, and the process continues to the next step(s), omitting the other branch from the workflow history.

The most common use case for the branch step is when most of the workflow steps are the same, but there are a couple points where the path may need to diverge based on different conditionals such as tasks or decision steps.

Where to Find This

This feature appears in the TDAdmin interface.

TDAdmin is where the application’s workflow is created and configured. TDNext is the interface where the workflow is executed.

Navigate to [name of the feature] following these paths:

• TDAdmin > Applications > [Ticketing application name] > Workflows > [Workflow name] > View Builder

Using the Branch Step

A branch step can fan out into separate multi-step paths which could run in parallel. You add steps to each branch in the workflow.

When a workflow reaches the branch step, it completes the step and continues on to the next steps, omitting the branch from the workflow history.

To create a branch step:

1. In TDAdmin, click Applications in the left navigation.
2. Click the Name of the Ticketing application you want to add a workflow to.
3. In the left navigation, click Workflows.
4. On the Ticket Workflows list, click the Name of the desired workflow.
5. Click the View Builder button.
6. In the Workflow Builder, click File in the toolbar.
7. Select Check Out from the dropdown.
8. Click the New Step button in the toolbar.
9. In the New Workflow Step window, enter a Name that indicates what the step will do.
10. Select the Branch Step Type from the dropdown.
11. Provide a description for what the branch is for (optional)
12. Click Save
13. Close the window showing the Branch Step details
14. The new Branch Step will now be available to use in the workflow
15. Click on the directional arrows and drag the Branch Step to the desired point in the workflow
16. If there is a preceding step to the branch, click on the preceding activity and drag to draw the connector to the Branch Step
17. Create the additional steps for the subsequent branches via New Step
18. Click and drag from Always on the Branch Step to draw connectors to each of the first steps for the respective branches

Gotchas & Pitfalls

1. Branch steps are a helpful way to provide descriptions and cleanly break out branches in a workflow.  However, they are optional to use.  An administrator can also simply draw multiple paths from any preceding step.  Therefore, one step can directly branch out into multiple other steps without using a Branch Step.

2. In larger workflows, you may need to include multiple branch steps to facilitate complexity. But, each time a branch step is added, it 'opens' that workflow path up, so then at the end, you need to 'close' that path with another branch. This is true for paths that have multiple branches. For example, if a path starts with a branch, and then another branch is needed within that path, then the end of that path would likely be 2 consecutive branches to 'close' out each of the first 2 branch steps. Then it can proceed forward to its next step, which is commonly a Collector step.

Examples

The primary use case for the branch step is when there are one or more workflow steps in separate branches that trigger the same set of parallel steps (such as tasks or decision steps). In such a case, it may help to decouple those linkages into a single step for ease of administration later on.

For example, when a request is added to the system, if it is an emergency change request it needs to be reviewed by the emergency CAB. If it is not and emergency change request, it needs to be reviewed by the standard CAB. In either case, upon approval by the appropriate CAB, a series of task steps fire off in parallel, then both paths flow through the same Change Approved step.

Imagine if a third step (task or otherwise) needed to start in parallel to those task steps. With the Change Approved branch step in place, it is simply a matter of adding the third step and connecting the branch step to it. Without the Branch step, administrators would have to manually connect the "Approve" options of both the ECAB Review and CAB Review to the new step, which increases the likelihood of error.