Overview: Decision workflow module (Edify Console)

Edify Console > Workflows > Workflow modules > Overview: Decision workflow module (Edify Console)

This article explains the Decision workflow module in Edify Console.

In this article

Overview

In Edify workflows, the decision module is used to compare an input value (like an incoming phone call or text message) with one or more logic checks. The decision module evaluates the incoming data and determines whether it passes or fails the logic check. Depending on the result, the decision module routes through either a valid or invalid exit port. This means that you can have branching workflow paths based on the result of a decision module.

For example, the decision module could be configured to analyze the area code of an inbound phone call. See the screenshot below for an example of this scenario.

In the screenshot above, the decision module immediately after the start module is configured to analyze if the source phone number (the phone number the phone call is originating from) has an area code from a list associated with Indianapolis area codes. 

If the decision module determines that the phone number does have an area code from the list, it routes it down the valid path to create an interaction in a certain queue. 

If it doesn’t have an area code from the list, it routes it down the invalid path, which leads to another decision module. This decision module checks if the phone number has an area code associated with Los Angeles. Again, if the phone number matches the logic, it routes down the valid path. Otherwise, it routes down the invalid path.

With the decision module, you can create highly-customizable workflows consisting of branching logic trees that are as simple or as complex as your business needs require.

Continue reading this article to learn more about how to configure a decision module to make your own custom logic checks in workflows.

Groups and rules

There are two key concepts that comprise the logic checking functionality of the decision module: groups and rules.

This section explores how to set up groups and rules in a decision module.

All decision modules start with a group containing an un-configured rule. The screenshot below shows a decision module with a group containing one rule.

In the screenshot above, the area surrounded in the rectangle is the group. It can contain several rules and sub-groups.

Notice in the top-left corner of the group is the AND / OR Selector (in the green rectangle in the screenshot below). This is where you configure how the decision module evaluates an input value against your rules.

There are two options:

We’ll explore the differences between these options below.

AND logic

The screenshot below is an example of a decision module set up with an AND group. 

In this example, there are three rules in the group with AND selected. That means we can read this group as:

With AND, if any of these conditions aren’t met, then the decision module routes down the invalid path. In other words, all of the conditions must be met. 

OR logic

Alternatively, you can set up your logic with OR. Let’s look at the exact same scenario as above, but with OR selected.

In this example, there are three rules with OR selected. This means we can read this group as:

With OR, only one of these conditions needs to be satisfied for the decision module to route down the valid path.

Adding additional groups

You can add multiple groups to create more complex logic in your decision modules.

In the screenshot below, there are two groups designated by rectangles.

The group on the top (surrounded by the orange rectangle) we can call Group A. The group on the bottom (surrounded by the green rectangle) we can call Group B.

We can read this as:

Meaning, if the input satisfies the requirements of Group A, or if the input satisfies the requirements of Group B, the decision module will route it down the valid path.

Notice that Group B has its own AND / OR selector. Also notice that Group B has two rules. This means that, in order for the input to satisfy the requirements of Group B, it must:

So, we can read this as:

You can make as simple or as complex logic structures by using the decision module.

Evaluators

Evaluators tell the decision module how to evaluate the input data.

The table below lists each of the evaluators and provides a brief description of its function.

How it works

Here is a simple use case for implementing a decision module in your workflow:

You can use a decision module to block a phone number from calling into a queue. 

With a decision module, you can make a list of phone numbers that the decision module will check against the source phone number of the interaction.

If the decision module detects that the source phone number is equal to the list of blocked phone numbers, it will route the workflow down a path that will reject the call.

Visual breakdown

Exterior structure

This is the exterior structure of a Decision module. All modules share this same structure.  

Reference the Overview: Workflow modules article to take a deeper dive into each of these components.

Interior structure

Below is the deep dive explanation for each interior area of the Decision module.

The screenshot above is what a fresh decision module looks like before any configuration.

The type menu is where you select what kind of value from the input you want to evaluate. In most circumstances, these are properties of an interaction.