--- title: Conditions Native Action slug: conditions-native-action docTags: createdAt: 2025-08-11T11:13:48.000Z --- 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 1. From the Add Panel, drag and drop the **Condition** action onto the playbook canvas. The TRUE and FALSE branches will automatically appear. 2. Click **Edit Condition** to open the window that allows you to enter the logic for your conditional statement. 3. 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. 4. 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: 1. In the Playbook area, drag and drop the **Condition Builder** into your workflow. 2. Use the right-side menu to click on the **Edit Condition** option, opening the **Condition Builder** dialog box. 3. In the dialog box, click **Create Your First Condition** to begin configuration. 4. From the dialog's right-hand options, choose a property to evaluate. 5. Open the Operator dropdown and select an operator based on your needs. For **Is defined**, **Is empty**, and **Is null** operators, see [Defined, Empty, and Null Operators](https://docs.swimlane.com/conditions-native-action#defined-empty-and-null-operators). You can also choose from other operators based on the property's data type (see the [Available Comparison Operators](https://docs.swimlane.com/conditions-native-action#available-comparison-operators) section for a complete list). :::hint{type="info"} Only property types listed under **Available Comparison Operators** are supported in the playbook Condition Builder. **Attachment** is not included. ::: 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 is a simple example to get started: **Goal**: Route high-severity incidents to a different action path 1. Drag and drop the Condition action onto your playbook canvas 2. Click **Edit Condition** 3. Click **Create Your First Condition** 4. Select property: `severity` 5. Choose operator: `Is equal to` 6. Enter value: `High` 7. Click **Apply** to save 8. Configure the True path to execute your high-priority action 9. Optionally configure an Else path for other severities 10. 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 1. When a condition action executes, it evaluates one or more conditions sequentially 2. If a condition evaluates to `true`, the workflow follows the associated action path 3. If no conditions evaluate to `true` and an `else` path is configured, the workflow follows the `else` path 4. 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 1. **Condition 1**: If `severity == "Critical"` → Execute "Critical Response" action 2. **Condition 2**: If `severity == "High"` → Execute "High Priority Response" action 3. **Condition 3**: If `severity == "Medium"` → Execute "Standard Response" action 4. **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 (for example, high → medium → low) - Handle multiple discrete cases that do not 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. ### Defined, Empty, and Null Operators The operator menu groups **defined**, **empty**, and **null** checks separately. Each group tests a different aspect of whether a property is set. | Operator | Description | Use Case | | ------------------ | --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | **Is empty** | The value is empty: `undefined`, `null`, a blank string (`""`), a zero-length array (`[]`), or an empty object (`{}`) | Checking that a field has no usable value | | **Is not empty** | The value is not empty | **Recommended** when you need a general check that a field is set to something meaningful | | **Is defined** | The expression resolves to a value that is not `undefined` (the property path exists on the source object) | Checking that a property exists, even if its value is `null` or empty | | **Is not defined** | The expression resolves to `undefined` (the property path does not exist on the source object) | Checking that a property is missing or unset | | **Is null** | The value is explicitly `null` | Distinguishing a property set to `null` from missing or empty | | **Is not null** | The value is not `null` | Ensuring a property is not explicitly set to `null` | :::hint{type="info"} For most validations, **Is not empty** is the best choice when you want to confirm that a field has a usable value. Use **Is defined** or **Is not defined** when you need to know whether a property path exists on the object. Use **Is null** or **Is not null** when you need to test for an explicit `null` value. ::: These operators appear in the Condition Builder for supported property types. The per-type tables below list which operators are available for each data type. ### Base Operators (Available for All Types) These operators are available regardless of the data type: | Operator | Description | Use Case | | --------------- | ------------------------------ | -------------------------------------------- | | **Is Null** | The value is explicitly `null` | Checking for a property set to `null` | | **Is Not Null** | The value is not `null` | Ensuring a property is not explicitly `null` | ### 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 empty** | The value is empty (see [Defined, Empty, and Null Operators](https://docs.swimlane.com/conditions-native-action#defined-empty-and-null-operators)) | N/A | Checking for blank or missing string values | | **Is not empty** | The value is not empty | N/A | Validating that a string field has a value | | **Is Defined** | The property path exists (value is not `undefined`) | N/A | Checking that a property is present on the object | | **Is Not Defined** | The property path does not exist (value is `undefined`) | N/A | Checking that a property is missing or unset | ### 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 empty** | The value is empty | Checking for missing numeric values | | **Is not empty** | The value is not empty | Validating numeric field presence | | **Is Defined** | The property path exists (value is not `undefined`) | Checking that a numeric property is set | | **Is Not Defined** | The property path does not exist (value is `undefined`) | Checking that a numeric property is unset | ### 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 (for example, "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 (for example, "next 5 minutes") | Upcoming events, time windows | | **Is empty** | The value is empty | Checking for missing date/time values | | **Is not empty** | The value is not empty | Validating date/time field presence | | **Is Defined** | The property path exists (value is not `undefined`) | Checking that a date/time property is set | | **Is Not Defined** | The property path does not exist (value is `undefined`) | Checking that a date/time property is unset | ### 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 empty** | The value is empty | Checking for missing boolean values | | **Is not empty** | The value is not empty | Validating boolean field presence | | **Is Defined** | The property path exists (value is not `undefined`) | Checking that a boolean property is set | | **Is Not Defined** | The property path does not exist (value is `undefined`) | Checking that a boolean property is unset | ### 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 empty** | The value is empty | N/A | Checking for missing array values | | **Is not empty** | The value is not empty | N/A | Validating array field presence | | **Is Defined** | The property path exists (value is not `undefined`) | N/A | Checking that an array property is set | | **Is Not Defined** | The property path does not exist (value is `undefined`) | N/A | Checking that an array property is unset | ### 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 empty** | The value is empty | Checking for missing array values | | **Is not empty** | The value is not empty | Validating array field presence | | **Is Defined** | The property path exists (value is not `undefined`) | Checking that an array property is set | | **Is Not Defined** | The property path does not exist (value is `undefined`) | Checking that an array property is unset | ### 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 empty** | The value is empty | Checking for missing object values | | **Is not empty** | The value is not empty | Validating object field presence | | **Is Defined** | The property path exists (value is not `undefined`) | Checking that an object property is set | | **Is Not Defined** | The property path does not exist (value is `undefined`) | Checking that an object property is unset | ### 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:** ```text 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:** ```text 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:** ```text 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 1. **Sequential Evaluation Only** - Conditions are evaluated sequentially, not in parallel - Evaluation stops at the first match 2. **No Loops** - Conditions cannot create loops or recursive logic - Each condition evaluates once per execution 3. **Property Access** - Only properties available in the current playbook context can be evaluated - Nested properties require proper path notation 4. **Operator Availability** - Operators are filtered based on data type - Some operators may not be available for all data types 5. **Unsupported Property Types in the Condition Builder** - **Attachment** fields and **attachment** playbook variables are not supported in the playbook Condition Builder in current releases - Selecting them in **Edit Condition** can show invalid UI or cause evaluation errors such as `Expression did not evaluate to boolean (object)` 6. **Application Workflow Conditions Are Different** - Application **workflow** conditions support attachment fields (**Has Value** / **Does Not Have Value**) - See **Creating Conditions** under Applications and Applets → Workflow for that behavior - That behavior does not apply to the playbook **Conditions** native action until product support is added 7. **Complex Expressions** - Complex calculations should be done in transformation actions before conditions - Conditions are best for simple comparisons and validations 8. **Performance** - Large numbers of conditions may impact performance - Consider breaking complex logic into multiple condition actions