An automation comprises three parts: a trigger (Figure 1 - 1), filters (Figure 1 - 2), and an action (Figure 1 - 3).

Once the automation is triggered, filters come into play to determine whether the automation should be executed or not. For instance, you can set a filter to make the automation run exclusively on Sundays.

This page presents an extensive list of automation filters, providing in-depth explanations and practical examples for each.

Filters

Filters (Figure 2) are defined by three different components:

• Condition (Figure 2 - 2): a set of pre-written comparison operators intended to link both the Event field and Match values.
• Event field (Figure 2 - 3): a property that contains a value provided by the Talkdesk system. It will be used to filter the automation based on the filled Match input and the chosen Condition.
• Match (UI input) (Figure 2 -1): a value filled by the customer that will be used to filter the automation according to the chosen Event field and Condition.

In this example, if Match (UI input) is filled as [email protected] (Figure 2 - 1) and the validation is set to Is equal (Figure 2 - 2), this filter will be applied when the Agent email (Figure 2 - 3) received in the event matches [email protected].

🚧

When a filter is applied, both the Event field value and the Match value are converted to strings beforehand. For instance, a Waiting Time value of 10.876 will be interpreted as "10.876".

The following table (Figure 3) provides details on scenarios where certain validation types do not work properly based on the Event field or Match types.

How Filters Operate

🚧

Each automation can be filtered by one or more filter conditions. However, this could be challenging because the conditions are grouped using the AND operator instead of the OR operator.
See the example below.

If you want to configure an automation, which executes whenever the Agent is Joseph or Luke, the approach presented in Figure 4 will not be suitable for this scenario.

This automation must only be executed if both conditions are true. See the scenario below (Figure 5) showing what happens when the following conditions are met.

Overcoming the OR Filter Condition

The solution involves creating another automation, containing each filter condition within its own automation.

Comparison Operators

Below, you can find each of the comparison operators used by the filter system, their implementation in Ruby, and their respective use case examples.

Contains

The received value contains the Match value, such as Sounding contains Sound.

value.include? match

Use Case

The Contains filter can be especially useful when dealing with event fields coming in lists format. When this filter is applied, both the Event field and Match are converted to strings beforehand.

For instance:

• A call duration value of 0 will be interpreted as "60".
• An agent’s ringing group value of ['agents'] will be interpreted as "['agents']".

1 - Event Field: String Type

For instance, when dealing with event fields in string format, you may want to validate whether an agent's name contains a specific surname. You can configure the filter as follows (Figure 6):

🚧

The Match input is case-sensitive (Waters isn't the same as waters).

In this case:

2 - Event Field: Numeric Type

When dealing with event fields in numeric format, you may want to validate whether the call duration contains a specific value. You can configure the filter as follows (Figure 7):

🚧

If the Match value comes in double format, it will not be cast into an integer. Instead, it will be represented as a string. For example, a value like 60.0 will be converted and used as "60.0".

In this case:

3 - Event Field: List Type

When dealing with event fields in list format, you may want to validate whether the agent who answered the call belongs to a specific ring group. You can configure the filter as follows (Figure 8):

🚧

The Match input is case-sensitive (Example isn't the same as example).

In this case:

Does Not Contain

The received value doesn't contain the Match value, such as Sound doesn't contain Sounding.

!value.include? match

Use Case - the Does Not Contain filter functions in a way diametrically opposed to the Contains filter. When this filter is applied, both the Event field and the Match are converted to strings beforehand.

For instance:

• A call duration with a value of 9 will be interpreted as "9".
• The agent's ringing groups, with a value of ['agents'], will be interpreted as "['agents']".

1 - Event Field: String Type

When dealing with event fields in string format, it becomes essential to validate certain criteria. For instance, you might want to check whether an agent's email does not contain a specific expression. To configure the filter for this purpose, follow these steps (Figure 9):

🚧

The Does Not Contain filter is case-sensitive, so talkdesk is not considered the same as Talkdesk.

In this case:

2 - Event Field: Numeric Type

When dealing with values in numeric format, you may need to validate whether a call duration doesn't contain a specific value. To configure the filter for this purpose, follow these steps (Figure 10):

🚧

If the Match value comes in double format, it will not be converted into an integer. It will be represented as a string. This means that 9.0 will be converted and used as "9.0".

In this case:

3 - Event Field: List Type

When dealing with event fields in list format, you may need to validate whether the agent who answered the call does not belong to a specific ring group. To configure the filter for this purpose, follow these steps (Figure 11):

🚧

The Match input is case-sensitive, which means that Example isn't the same as example.

In this case:

Is Set

The received value is defined. Depending on the mandatoriness of the field, the received value can either be defined or empty.

!value.blank?

Use Case - The Is Set filter validates whether an Event field is present in the event or not. This is very useful, especially considering that not all fields are mandatory. When this filter is applied, both the Event field and the Match are converted to strings beforehand.

For instance:

• A total duration with a value of 60 will be interpreted as "60".
• The agent's ringing groups, with a value of ['agents'], will be interpreted as "['agents']".

1 - Event Field: String Type

For instance, when dealing with event fields in string format, you may want to check whether the content of a note is not empty. Following this example, you can configure the filter as follows (Figure 12).

In this case:

1 - Event Field: Numeric Type

When dealing with event fields in numeric format, you may want to validate if the total duration of a call is set. Following this example, you can configure the filter as follows (Figure 13):

In this case:

2 - Event Field: List Type

When dealing with event fields in list format, you may want to validate whether the agent that answered the call has agent ringing groups set. You can configure the filter as follows (Figure 14):

Is Not Set

The received value is empty. Depending on the mandatoriness of the field, the value received can be defined or empty.

value.blank?

Use Case - the Is Not Set filter performs the opposite function compared to the Is Set filter. When the Is Not Set filter is applied, both the Event field and the Match are converted to strings beforehand.

For instance:

• If the total duration is 60, it will be interpreted as "60".
• If the agent's ringing groups have a value of ['agents'], it will be interpreted as "['agents']".

1 - Event Field: String Type

When dealing with event fields in string format, you may want to check if a note is empty. You can configure the filter as follows (Figure 15):

In this case:

2 - Event Field: Numeric type

When dealing with event fields in the numeric format, you may want to validate if the total duration of a call isn't set. You can configure the filter as follows (Figure 16):

In this case:

3 - Event Field: List Type

When dealing with event fields in list format, you may want to validate whether the agent that answered the call has no agent ringing groups set. You can configure the filter as follows (Figure 17):

In this case:

Is Equal

The received value is exactly the same as the Match value.

return value.nil? if match.nil?

truth_map = %w(true false)
filter_match = truth_map.include?(match.downcase) ? match.downcase : match

filter_match.eql? value

Use Case - the Is Equal filter performs exactly as the name suggests; it validates equality between two values. This trigger allows you to evaluate whether the Event field value is an exact match with the specified Match value. When applying this filter, both the Event field and the Match are converted to strings beforehand.

For instance:

• A voicemail duration with a value of 0 will be interpreted as "0".
• Agent's ringing groups with a value of ['agents'] will be interpreted as "['agents']".

1 - Event Field: String Type

When dealing with event fields in string format, you may need to check if a note title's content matches exactly a specific sentence, word, or character. You can configure the filter as follows (Figure 18):

🚧

The Match input is case-sensitive, meaning that Note's isn't the same as note's.

In this case:

2 - Event Field: Numeric Type

When dealing with numeric values, you may need to validate whether a voicemail duration is equal to a specific value. You can configure the filter as follows (Figure 19):

🚧

If the Match value comes in double format, it will not be converted into an integer, but rather into a string . For instance, 0.0 will be converted and used as "0.0".

In this case:

3 - Event Field: List Type

When dealing with event fields in list format, you may need to validate whether the agent who answered the call belongs to a specific ringing group or set of ringing groups. You can configure the filter as follows (Figure 20):

🚧

The Match input is case-sensitive, indicating that Agents is not considered the same asagents.

Furthermore, in this case, the order of the elements in the list matters. This means that ["agents", "test"] is different from ["test", "agents"].

In this case:

Not Equal

The received value isn’t the same as the Match value.

!match.eql? value

Use Case - the Not Equal filter performs precisely as its name suggests; it validates non-equality between two values. This trigger allows you to evaluate whether the Event field value is not identical to the specified Match value. When applying this filter, both the Event field and Match are converted to strings beforehand.

For instance:

• A voicemail duration with a value of 0 will be interpreted as "0".
• Agent's ringing groups with a value of ['agents'] will be interpreted as "['agents']".

1 - Event Field: String Type

For example, when dealing with event fields in string format, you may wish to verify whether the note title is different from the provided Match value. You can configure the filter as follows (Figure 21):

🚧

The Match input is case-sensitive, meaning that Note's isn't the same as note's.

In this case:

2 - Event Field: Numeric Type

When dealing with values in numeric format, you may need to validate whether a voicemail duration differs from a specific value. You can configure the filter as follows (Figure 22):

🚧

If the Match value comes in double format, it will not be converted into an integer, but rather into a string. For instance, 0.0 will be converted and used as "0.0".

In this case:

3 - Event Field: List type

When dealing with event fields in list format, you may need to validate whether the agent who answered the call does not belong to a specific ringing group or set of ringing groups. You can configure the filter as follows (Figure 23):

🚧

The Match input is case-sensitive, indicating that Agents is not considered the same asagents.

Furthermore, in this case, the order of the elements in the list matters. This means that ["agents", "test"] is different from ["test", "agents"].

Begins With

The received value starts with the Match value.

value.start_with?(match) rescue false

Use Case - the Begins With filter performs exactly as its name suggests; it validates whether the value received from the event trigger starts with a certain value. When applying this filter, both the Event field and the Match are converted to strings beforehand.

For instance:

• A caller's number with a value of +1 123 456 789 will be interpreted as "+1 123 456 789".
• Voicemail duration with a value of 0 will be interpreted as "0".
• Agent's ringing groups with a value of ['agents'] will be interpreted as "['agents']".

1 - Event Field: String Type

For example, when dealing with event fields in string format, you may want to check whether a caller's number starts with a specific country code. You can configure the filter as follows (Figure 24):

🚧

The Match input is case-sensitive, meaning that +1 A is not the same as +1 a.

In this case:

2 - Event Field: Numeric Type

When dealing with values in numeric format, you may need to validate whether a voicemail duration starts with a specific value. You can configure the filter as follows (Figure 25):

🚧

If the Match value comes in double format, it will not be converted into an integer, but rather into a string. For instance, 0.0 will be converted and used as "0.0".

In this case:

3 - Event Field: List type

When dealing with event fields in list format, you may need to validate whether the agent who answered the call does not belong to a specific ringing group or set of ringing groups. You can configure the filter as follows (Figure 26):

🚧

The Match input is case-sensitive, indicating that Agents is not considered the same asagents.

Furthermore, in this case, the order of the elements in the list matters. This means that ["agents", "test"] is different from ["test", "agents"].

In this case:

Ends With

The received value ends with the Match value.

value.end_with?(match) rescue false

Use Case - the Ends With filter performs exactly as its name suggests; it validates that the value received from the event triggered ends with a certain value. When applying this filter, both the Event field and the Match are converted to strings beforehand.

For instance:

• An agent's email with a value of [email protected] will be interpreted as "[email protected]".
• Voicemail duration with a value of 0 will be interpreted as "0".
  Agent's ringing groups with a value of ['agents'] will be interpreted as "['agents']".

1 - Event Field: String Type

For example, when dealing with event fields in string format, you may want to check whether an agent's email ends with a specific domain. You can configure the filter as follows (Figure 27):

🚧

The Match input is case-sensitive, meaning that @talkdesk is not the same as @Talkdesk.

In this case:

2 - Event Field: Numeric Type

When dealing with numeric values, you may need to validate whether a voicemail duration ends with a specific value. You can configure the filter as follows (Figure 28):

🚧

If the Match value comes in double format, it will not be converted into an integer, but rather into a string. For instance, 0.0 will be converted and used as "0.0".

In this case:

3 - Event Field: List Type

When dealing with event fields in list format, you may need to validate whether the agent who answered the call belongs to a set of ringing groups that start with a specific ringing group. You can configure the filter as follows (Figure 29):

🚧

The Match input is case-sensitive, indicating that Agents is not considered the same asagents.

Furthermore, in this case, the order of the elements in the list matters. This means that ["agents", "test"] is different from ["test", "agents"].

In this case:

Greater Than

The received value is higher than the Match value. This only works with numbers (don’t expect it to work with dates, for example).

Float(value) > Float(match) rescue false

Use Case - the Greater Than filter does exactly what it suggests: it compares two values to validate if the event field argument is bigger than the given value. This can be especially useful when dealing with event fields containing numerical values. When this filter is applied, both the Event field and Match are converted to Float beforehand.

For instance: a call's total duration with a value of 60 will be interpreted as 60.0.

1 - Event Field: String Type

❗️

The Greater Than filter does not apply to the string use case.

2 - Event Field: Numeric Type

For example, when dealing with event fields in numeric format, you may want to check whether a call's total duration is longer than a specific value. You can configure the filter as follows (Figure 30):

🚧

The Match value comes in an integer or string format, it will be converted into a float. This means that 0 or "0" will be converted and used as 0.0.

In this case:

3 - Event Field: List Type

❗️

The Greather Than filter does not apply to the list use case.

Less Than

The received value is lower than the Match value. Just like with Greater Than, Less Than only works with numbers.

Float(value) < Float(match) rescue false

Use Case - The Less Than filter does exactly what it suggests; it compares two values to validate if the event field argument is smaller than the given value. This can be especially useful when dealing with event fields containing numerical values. When this filter is applied, both the Event field and Match are converted to Float beforehand.

For instance: a call's total duration with a value of 60 will be interpreted as 0.60.

1 - Event Field: String type

❗️

The Less Than filter does not apply to the string use case.

2 - Event Field: Numeric type

For example, when dealing with event fields in numeric format, you may want to check whether a call's total duration is shorter than a specific value. You can configure the filter as follows (Figure 31):

🚧

The Match value comes in an integer or string format, it will be converted into a float. This means that 0 or "0" will be converted and used as 0.0.

In this case:

3 - Event Field: List Type

❗️

The Less Than filter does not apply to the list use case.

Is One Of

The Match value matches either of the received values when they are comma-separated (and whitespace is ignored).

return false if match.nil? || value.nil?

matches = match.to_s.split(',').map(&:strip)

matches.include? value

Use Case - the Is One Of filter can be particularly useful when there are multiple possible outcomes (matches) for one Event field (value). When applying this filter, both the Event field and Match are converted to string beforehand.

For instance:

• An agent's name with a value of Mark will be interpreted as "Mark".
• Call duration with a value of 60 will be interpreted as "60".
• Agent’s ringing groups with a value of ['agents'] will be interpreted as "['agents']".

1 - Event Field: String Type

For example, when dealing with event fields in string format, you may want to validate whether the agent's name is present in a list. You can configure the filter as follows (Figure 32):

🚧

Each possible outcome presented in the match section is separated by a comma. Also, this filter is case-sensitive, meaning that Mark isn't the same as mark.

In this case:

2 - Event Field: Numeric Type

When dealing with numeric values, you may want to validate whether the call duration matches any value from a certain list. You can configure the filter as follows (Figure 33):

🚧

If the Match value comes in double format, it will not be converted into an integer. Instead, it will be represented as a string. For example, values like 0.0 or 60.0 will be converted and used as "0.0", "60.0".

In this case:

3 - Event Field: List Type

❗️

The Is One Off filter does not apply to the list use case.

This filter does not function as intended when dealing with list values. You may want to validate whether a specific ringing group is present in the agent's ringing groups. However, configuring the filter as follows will not work (Figure 34):

In this case:

🚧

Even if you change the order of the values, this will still not work as expected.

In this case: