Conditions
How a condition tests one field of the run's data, the operators available per field type, the full list of testable fields, and how True/False branching works.
A condition node tests one field of the data flowing through the run, and routes the workflow through its True output when the test passes or its False output when it fails.
A condition can only test what the nodes before it published: the trigger always publishes the ticket's data, and each action publishes what it did. So a condition placed right after the trigger tests the ticket, while one placed after an action can also test that action's outcome.
Operators
The operators offered depend on the field's type.
Text — statuses, priority, subject, form button, message content:
is · is not · is one of · contains · does not contain · starts with · does not start with · ends with · does not end with · is empty · is not empty · matches regex · does not match regex · exists · does not exist
List — tags, packages, assignees (a ticket can have several of each):
contains · does not contain · contains any of · contains none of · is not · is empty · is not empty · length is · length is not · length is greater than · length is less than · length is at least · length is at most
Yes/no — what an action reports about itself (whether it changed anything, whether a call succeeded):
is true · is false · exists · does not exist
A few rules worth knowing:
- Presence operators (is empty, exists, is true, and their negatives) take no value.
- Matches regex runs the pattern with a linear-time engine, so it is safe against malicious patterns; patterns are capped at 200 characters.
- Length operators compare against a whole number (
0and up). - A condition on a field the workflow does not provide keeps it a draft — it can still be saved, but not enabled — and the editor names the node and the missing field so you can fix it.
Fields every trigger publishes
| Field | Type | Value |
|---|---|---|
| Ticket number | Text | Typed |
| Subject | Text | Typed |
| Current status | Text | Picked from the status list |
| Priority | Text | Picked from the priority list |
| Tags | List | Typed |
| Packages | List | Picked from your Tebex catalog |
| Package ID (manual entry) | List | Typed — for a package that was disabled or pulled from the shop, which no catalog list offers |
| Package names | List | Typed |
| Form button | Text | Typed |
| Assignees | List | Picked from the project's members |
| Customer name | Text | Typed |
| Project name | Text | Typed |
Fields a specific trigger adds
| Field | Type | Trigger |
|---|---|---|
| Previous status | Text | Status changed |
| New status | Text | Status changed |
| Ticket source | Text | Ticket creation |
| Message author type | Text | On chat message |
| Message content | Text | On chat message |
| Message author | Text | On chat message |
| Message ID | Text | On chat message |
| Selected packages | List | Package selected |
| Selected package ID (manual entry) | List | Package selected |
| Selected package names | List | Package selected |
Fields an action adds
Place the condition after the action to test these.
| Field | Type | Published by |
|---|---|---|
| Posted message ID, Posted message type, Posted message content | Text | Post message |
| Chosen option ID, Chosen option label | Text | Post message, when it offers choices |
| Scheduled closure date | Text | Schedule closure |
| Closure skipped | Yes/no | Schedule closure |
| Linked package IDs, Linked package names | List | Set package, Ask for the package |
| Package changed | Yes/no | Set package |
| Package unlinked | Yes/no | Unlink package |
| Unlinked package names | List | Unlink package |
| Assignee ID, Assignee name | Text | Assign to a user |
| Assignee changed | Yes/no | Assign to a user |
| New priority, Previous priority | Text | Set priority |
| Priority changed | Yes/no | Set priority |
| Notification sent | Yes/no | Discord notification |
| Notified channel ID | Text | Discord notification, to a channel |
| Direct messages delivered, Recipients skipped | Text | Discord notification, as direct messages |
| Webhook succeeded | Yes/no | Call a webhook |
| Webhook HTTP status | Text | Call a webhook |
| AI confidence | Text | Ask AI |
| AI asked for a human | Yes/no | Ask AI |
Branching
Connect the condition's True output to what should happen when it matches, and its False output to what should happen otherwise.
- If a condition evaluates False and its False output is not connected, that branch stops there and the run is recorded as Condition not met. This reproduces a simple filter, and other branches of the same run, if any, still complete.
- Several conditions chained through their True outputs act as an AND.
- A Condition not met run costs nothing against your monthly quota, so conditions are free to use as filters.
Example
Urgent tickets about one package go straight to the specialist, the others just get tagged.Ticket creation → condition Packages contains any of
Premium Script,Premium Script Pro→ True: Assign to a user (the specialist), then Discord notification to your team channel → False: Post message as an internal note, so whoever picks the ticket up knows it was not routed.