Condition Step

In this article, we'll cover:

• Overview
• Where to Find This
• Configuring a Condition Step
• Examples

Overview

Condition steps are binary: each one evaluates to either Condition Met or Condition Not Met, so if you need to route a ticket down more than two paths, you'll need to add additional Condition steps. To sift through ticket data for multiple criteria, Condition steps can be daisy-chained together to account for all the different options or paths you need.

Once the Condition step is saved, you connect the Condition Met and Condition Not Met options to the steps that should occur next.

A Condition step can't be owned by a person — it's evaluated automatically by the system. When the system evaluates the step in a ticket's workflow, the result is recorded in the workflow history, and subsequent steps proceed based on the outcome.

In the above image, a Task step ("Set Maintenance Activities") completes and flows into a Condition step named "Emergency Change?" Based on the result, the workflow routes to one of two Approval steps: if Condition Met, it follows the green path to an "Emergency Approval" step; if Condition Not Met, it follows the red path to a "Service owner approval" step.

Where to Find This

The Condition step is configured in the Ticketing application admin interface, and can be viewed on a ticket with the workflow applied in Work Management and the Client Portal.
Configure the step from the Workflow Builder in the Ticketing app admin UI following these paths:

• Ticketing Application Admins: Work Management > View Applications > [name of the Ticketing application]  > gear icon > Admin > Workflows > [Workflow name] > View Builder 
• Global Admins: TDAdmin > Applications > [name of the Ticketing application]  > Workflows > [Workflow name] > View Builder

Access an active workflow:

• In Work Management > View Applications > [name of the Ticketing application]  > find the ticket with the workflow applied and review the step
• In the Client Portal > Ticket Requests > open the request and review the workflow steps

To create and set up a Condition step:

1. In the Ticketing application admin UI, navigate to the Workflows page, and click the workflow name.
2. Click the View Builder button.
3. In the Workflow Builder, click File in the toolbar and select Check Out from the dropdown.
4. Click the New Step button in the toolbar.
5. In the New Workflow Step window, enter a Name that indicates what the condition is checking (for example, "Emergency Change?"). This name appears on the workflow step.
6. Select the Condition step Type from the dropdown.
7. If Stages have been configured for the workflow, optionally select one from the Stage dropdown.
8. Optionally enter a Description for the step.
9. Under Conditions, several blank condition rows are available by default. In the Column field of a row, type or use the lookup (magnifying glass) to find the ticket property you want to evaluate. The lookup includes standard ticket fields (some grouped under Budget Information, Requestor, or Responsibility) as well as custom attributes, which are grouped by application and attribute type (for example, a dropdown list attribute under IT Tickets > Custom Attributes).
10. Select an Operator that defines how the property's value must compare (for example, "is one of").
11. In the Value(s) field, select from the available options if the property has a fixed set of values, or enter a value directly if it's a free-text field.
12. Repeat for any additional conditions the ticket must meet, using Add to create more rows or Remove to delete one you don't need. By default, a ticket must meet all listed conditions.
13. If you need OR logic instead of (or alongside) requiring all conditions, click Show Advanced to reveal the Advanced Filter Expression field, then enter your logic referencing each condition by its row number — for example, "(1 OR 2) AND 3".
14. Click Save and close the window.

On the Workflow Builder, the Condition step shows the step name and two options: Condition Met and Condition Not Met. These function as a yes/no or true/false result for the configured condition. For example, on a Condition step named "Emergency Change?" with "Change Type is one of Emergency" configured, a ticket where Change Type is "Emergency" would be Condition Met; any other Change Type value would be Condition Not Met.

Examples

When combined with Branch and Collector steps, a Condition step can account for multiple scenarios within a workflow. Based on the data submitted on the ticket—attributes, priority, and so on—the ticket flows through the desired paths in the workflow.

The Client Response Timer workflow example, uses repeated Condition steps to check whether a ticket is still in an On Hold status after a wait period. Each Condition step checks the ticket's Status against the On Hold classification used to mark it as waiting on the requestor. Condition Met (still on hold, meaning no response) leads to another reminder notification, while Condition Not Met (off hold, meaning the requestor responded) ends the workflow without making further changes to the ticket. See the Client Response Timer Workflow Example for full setup details.

In the Banner Programming Approvals workflow example below, the workflow starts by branching into multiple Condition steps, and based on the data, the Condition steps determine which paths the ticket will take. This can reduce the number of workflows you need to build, maintain, and report on for specific requests.