Conditions Native Action

33 min

Overview

The Conditions Native Action enables you to introduce if/else logic into your playbooks, executing different paths based on the evaluation of specific criteria. This action supports the customization and automation of playbooks by visually representing decision-making flows.

Key Concepts

Condition: A set of criteria that, when evaluated, determines which path the workflow follows

True Path (If): The path executed when a condition evaluates to true

False Path (Else): The optional path executed when no conditions evaluate to true

Condition Builder: The visual interface for creating and configuring conditions

Getting Started

Prerequisites

Before using the Conditions Native Action, ensure you have:

Access to playbook creation and editing

Understanding of your data structure and available properties

Basic knowledge of the playbook workflow

Steps to Add and Configure Condition

From the Add Panel, drag and drop the Condition action onto the playbook canvas. The TRUE and FALSE branches will automatically appear.

Click Edit Condition to open the window that allows you to enter the logic for your conditional statement.

If your data has any sensitive information, you can mark it as sensitive by clicking the Contains sensitive data checkbox. The data is not shown in the UI or in the logs.

Click Apply to save changes.

TRUE and FALSE Logic

When you drag and drop a Condition native action onto the playbook canvas, the TRUE and FALSE flows automatically display:

TRUE (IF): If the condition is met, the workflow follows the TRUE path

FALSE (ELSE): If the condition is not met, the workflow follows the FALSE path

Using the Condition Builder

The Condition Builder provides a visual interface for creating conditions. Follow these steps to create your first condition:

In the Playbook area, drag and drop the Condition Builder into your workflow.

Use the right-side menu to click on the Edit Condition option, opening the Condition Builder dialog box.

In the dialog box, click Create Your First Condition to begin configuration.

From the dialog's right-hand options, choose a property to evaluate.

Open the Operator dropdown and select an operator based on your needs.

Note: New conditions Is Defined and Is Not Defined are available in the Condition Builder, enabling you to check whether a specific field has a value or is empty:

Is Defined: Verifies that a field is filled or contains valid data

Is Not Defined: Identifies fields that are empty or missing

These conditions are particularly valuable for creating rules where the presence or absence of data is crucial, such as validating inputs or filtering results.

You can also choose from other operators based on the property's data type (see the Available Comparison Operators section for a complete list).

If the operator requires a comparison value, enter it in the provided field.

Save the condition and test it within your playbook to ensure it operates as intended.

Your First Condition Example

Here's a simple example to get started:

Goal: Route high-severity incidents to a different action path

Drag and drop the Condition action onto your playbook canvas

Click Edit Condition

Click Create Your First Condition

Select property: severity

Choose operator: Is equal to

Enter value: High

Click Apply to save

Configure the True path to execute your high-priority action

Optionally configure an Else path for other severities

Test the condition with sample data

Common Use Cases

Use Case 1: Severity-Based Routing

Route incidents to different teams based on severity level.

Configuration:

Condition 1: severity == "Critical" → Critical Response Team

Condition 2: severity == "High" → High Priority Team

Condition 3: severity == "Medium" → Standard Team

Else: Low Priority Queue

Use Case 2: Time-Based Actions

Execute different actions based on when an incident was created.

Configuration:

Condition 1: createdAt Is in the previous 1 hour → Immediate Response

Condition 2: createdAt Is in the previous 24 hours → Standard Response

Else: Archive and Review

Use Case 3: Status Validation

Ensure incidents meet certain criteria before processing.

Configuration:

Condition Group (AND):

status == "Open" AND

assignedTo Is Not Null AND

priority > 5

True Path: Process Incident

Else: Queue for Assignment

Use Case 4: Threat Detection

Trigger automated responses for security threats.

Configuration:

Condition Group (AND):

category == "Security" AND

(severity == "High" OR severity == "Critical") AND

indicators Contains "malicious-domain.com"

True Path: Automated Containment

Else: Standard Investigation

Use Case 5: Data Validation

Validate data before processing to prevent errors.

Configuration:

Condition: requiredField Is Defined AND email Matches (regex pattern)

True Path: Process Data

Else: Send Validation Error

How Conditions Work

Basic Flow

When a condition action executes, it evaluates one or more conditions sequentially

If a condition evaluates to true, the workflow follows the associated action path

If no conditions evaluate to true and an else path is configured, the workflow follows the else path

If no conditions match and no else path is configured, the condition action completes without executing any path

Evaluation Order

Conditions are evaluated in the order they are configured. The first condition that evaluates to true determines the path taken. Subsequent conditions are not evaluated once a match is found.

Multiple Conditions Behavior

Understanding Multiple Conditions

A single condition action can contain multiple conditions. Each condition can route to a different action path.

Important: Multiple conditions behave like an if-else if-else chain:

Conditions are evaluated sequentially from first to last

The first condition that evaluates to true determines the path

Once a condition matches, evaluation stops (no further conditions are checked)

If no conditions match, the else path is taken (if configured)

Example: Multiple Conditions

Scenario: Route incidents based on severity level

Condition 1: If severity == "Critical" → Execute "Critical Response" action

Condition 2: If severity == "High" → Execute "High Priority Response" action

Condition 3: If severity == "Medium" → Execute "Standard Response" action

Else: Execute "Low Priority Response" action

Execution Flow:

If severity is "Critical", only Condition 1 is evaluated and matched

If severity is "High", Condition 1 is evaluated (false), then Condition 2 is evaluated and matched

If severity is "Low", all three conditions are evaluated (all false), then the else path is taken

When to Use Multiple Conditions

Use multiple conditions when you need to:

Route to different actions based on different values of the same property

Create priority-based routing (e.g., high → medium → low)

Handle multiple discrete cases that don't require complex logic

Available Comparison Operators

The condition builder provides different operators based on the data type of the property being evaluated. Operators are automatically filtered based on the selected property's type.

Base Operators (Available for All Types)

These operators are available regardless of the data type:

Operator	Description	Use Case
Is Null	Checks if the property value is null	Validating required fields, checking for missing data
Is Not Null	Checks if the property value is not null	Ensuring data exists before processing

String Operators

Available when evaluating string properties:

Operator	Description	Case Sensitive	Use Case
Is equal to	Exact string match	Yes	Matching exact values like status codes
Is equal to (case insensitive)	Exact string match ignoring case	No	Matching values regardless of capitalization
Is not equal to	String does not match	Yes	Excluding specific values
Is not equal to (case insensitive)	String does not match ignoring case	No	Excluding values regardless of case
Matches	Regular expression pattern match	Yes	Pattern matching, validation
Matches (case insensitive)	Regular expression pattern match ignoring case	No	Case-insensitive pattern matching
Does not match	Regular expression pattern does not match	Yes	Excluding patterns
Does not match (case insensitive)	Regular expression pattern does not match ignoring case	No	Case-insensitive pattern exclusion
Is Defined	Checks if the property has a value (not null, not undefined, not empty)	N/A	Validating field presence
Is Not Defined	Checks if the property is empty or missing	N/A	Checking for missing or empty fields

Numeric Operators

Available when evaluating numeric properties:

Operator	Description	Use Case
Is equal to	Exact numeric match	Matching specific numeric values
Is not equal to	Numeric value does not match	Excluding specific values
Is greater than	Value is greater than the comparison value	Threshold checks, minimum requirements
Is greater than or equal to	Value is greater than or equal to the comparison value	Inclusive threshold checks
Is less than	Value is less than the comparison value	Maximum limits, upper bounds
Is less than or equal to	Value is less than or equal to the comparison value	Inclusive maximum limits
Is Defined	Checks if the property has a numeric value	Validating numeric field presence
Is Not Defined	Checks if the property is empty or missing	Checking for missing numeric values

Date/Time Operators

Available when evaluating date/time properties:

Operator	Description	Use Case
Is equal to	Exact date/time match	Matching specific dates/times
Is not equal to	Date/time does not match	Excluding specific dates/times
Is after	Date/time is after the comparison value	Future date checks, expiration validation
Is on or after	Date/time is on or after the comparison value	Inclusive future date checks
Is before	Date/time is before the comparison value	Past date checks, creation date validation
Is on or before	Date/time is on or before the comparison value	Inclusive past date checks
Is sometime in the past	Date/time is in the past (relative)	General past date validation
Is in the previous	Date/time is within a previous time period (e.g., "last 5 minutes")	Recent past events, time windows
Is sometime in the future	Date/time is in the future (relative)	General future date validation
Is in the next	Date/time is within a future time period (e.g., "next 5 minutes")	Upcoming events, time windows
Is Defined	Checks if the property has a date/time value	Validating date/time field presence
Is Not Defined	Checks if the property is empty or missing	Checking for missing date/time values

Boolean Operators

Available when evaluating boolean properties:

Operator	Description	Use Case
Is true	Property value is true	Checking for true conditions, flags
Is false	Property value is false	Checking for false conditions, negated flags
Is Defined	Checks if the property has a boolean value	Validating boolean field presence
Is Not Defined	Checks if the property is empty or missing	Checking for missing boolean values

String Array Operators

Available when evaluating string array properties:

Operator	Description	Case Sensitive	Use Case
Contains	Array contains the specified string	Yes	Checking if an array includes a value
Contains (case insensitive)	Array contains the specified string ignoring case	No	Case-insensitive array membership check
Does not contain	Array does not contain the specified string	Yes	Excluding arrays with specific values
Does not contain (case insensitive)	Array does not contain the specified string ignoring case	No	Case-insensitive exclusion check
Is Defined	Checks if the property has an array value	Validating array field presence
Is Not Defined	Checks if the property is empty or missing	Checking for missing array values

Numeric Array Operators

Available when evaluating numeric array properties:

Operator	Description	Use Case
Contains	Array contains the specified number	Checking if an array includes a numeric value
Does not contain	Array does not contain the specified number	Excluding arrays with specific numeric values
Is Defined	Checks if the property has an array value	Validating array field presence
Is Not Defined	Checks if the property is empty or missing	Checking for missing array values

Object Operators

Available when evaluating object properties:

Operator	Description	Use Case
Equals	Deep equality comparison of objects	Comparing complex objects
Not equals	Objects are not equal	Excluding specific object structures
Is Defined	Checks if the property has an object value	Validating object field presence
Is Not Defined	Checks if the property is empty or missing	Checking for missing object values

String List Operators

Available when evaluating properties that can match against a list of strings:

Operator	Description	Case Sensitive	Use Case
Is equal to	Value matches one of the list items	Yes	Matching against predefined lists
Is equal to (case insensitive)	Value matches one of the list items ignoring case	No	Case-insensitive list matching
Is not equal to	Value does not match any list items	Yes	Excluding values from a list
Is not equal to (case insensitive)	Value does not match any list items ignoring case	No	Case-insensitive list exclusion

Condition Groups and AND/OR Logic

Understanding Condition Groups

Condition Groups allow you to combine multiple criteria within a single condition using AND/OR logic. This is different from multiple conditions (which use sequential if-else logic).

Condition Groups vs. Multiple Conditions

Feature	Multiple Conditions	Condition Groups
Logic Type	Sequential if-else if-else	AND/OR boolean logic
Evaluation	First match wins, stops evaluation	All criteria evaluated together
Use Case	Routing to different actions	Complex validation requiring multiple criteria
Structure	Separate conditions, each routes to different action	Single condition with grouped criteria

AND Logic

When using AND logic, all criteria in the group must evaluate to true for the condition to be true.

Example:

Condition Group (AND):
  - severity == "High" AND
  - status == "Open" AND
  - priority > 5
→ All three must be true for the condition to match

OR Logic

When using OR logic, any criterion in the group that evaluates to true makes the condition true.

Example:

Condition Group (OR):
  - severity == "Critical" OR
  - severity == "High" OR
  - priority > 8
→ Any one being true makes the condition match

Combining AND and OR

You can create nested condition groups to combine AND and OR logic:

Example:

Condition Group (AND):
  - (severity == "High" OR severity == "Critical") AND
  - status == "Open" AND
  - (priority > 5 OR assignedTo != null)

This condition matches when:

Severity is High OR Critical, AND

Status is Open, AND

Priority is greater than 5 OR the incident is assigned

When to Use Condition Groups

Use condition groups when you need to:

Validate multiple criteria simultaneously

Create complex boolean logic

Ensure all conditions must be met (AND) or any condition can be met (OR)

Use multiple conditions when you need to:

Route to different actions based on different values

Create priority-based routing

Handle discrete cases

Limitations

Sequential Evaluation Only

Conditions are evaluated sequentially, not in parallel

Evaluation stops at the first match

No Loops

Conditions cannot create loops or recursive logic

Each condition evaluates once per execution

Property Access

Only properties available in the current playbook context can be evaluated

Nested properties require proper path notation

Operator Availability

Operators are filtered based on data type

Some operators may not be available for all data types

Complex Expressions

Complex calculations should be done in transformation actions before conditions

Conditions are best for simple comparisons and validations

Performance

Large numbers of conditions may impact performance

Consider breaking complex logic into multiple condition actions