# Conditions
URL: /response-workflows/conditions
Type: reference
Description: Filter which tickets a Response Workflow applies to based on ticket fields, tags, and custom data.
Keywords: conditions, filter, ticket fields, tags
Conditions let you control exactly which tickets a Response Workflow runs on. Instead of matching every ticket, you can filter by ticket status, channel, tags, requester info, and custom fields — ensuring the workflow only fires when it's relevant.

How conditions work [#how-conditions-work]

Conditions are evaluated before a workflow executes. If the ticket doesn't match the conditions, the workflow is skipped entirely — no response is generated, no resources are used.

Conditions use three logic groups that are combined with AND:

| Group       | Logic | Meaning                                    |
| ----------- | ----- | ------------------------------------------ |
| **All of**  | AND   | Every condition in this group must be true |
| **Any of**  | OR    | At least one condition must be true        |
| **None of** | NOT   | No condition in this group can be true     |

All three groups must pass for the workflow to run. If any group fails, the workflow is skipped.

**Example:** A workflow that handles refund requests might use:

* **All of:** Status is "open", Channel is "email"
* **Any of:** Tags contain "refund" OR Subject contains "return"
* **None of:** Tags contain "vip" (VIP customers get routed to a senior agent instead)

Available fields [#available-fields]

Standard ticket fields [#standard-ticket-fields]

| Field        | Type | Description                                                |
| ------------ | ---- | ---------------------------------------------------------- |
| **Subject**  | Text | The ticket subject line                                    |
| **Status**   | Text | Current ticket status (new, open, pending, solved, closed) |
| **Channel**  | Text | How the ticket was created (email, web, chat, phone, etc.) |
| **Priority** | Text | Ticket priority level (low, normal, high, urgent)          |
| **Tags**     | Tags | Tags applied to the ticket                                 |

People fields [#people-fields]

| Field                 | Type | Description                  |
| --------------------- | ---- | ---------------------------- |
| **Requester name**    | Text | The customer's name          |
| **Requester email**   | Text | The customer's email address |
| **Assignee name**     | Text | The assigned agent's name    |
| **Organization name** | Text | The requester's organization |

Custom fields [#custom-fields]

You can also filter on Zendesk custom fields. Select the field from the dropdown and choose the appropriate operator for the field type (text, number, or dropdown).

Operators [#operators]

Text fields [#text-fields]

| Operator         | Matches when...                                  |
| ---------------- | ------------------------------------------------ |
| **Equals**       | Field value exactly matches the specified value  |
| **Not equals**   | Field value does not match                       |
| **Contains**     | Field value includes the specified text anywhere |
| **Not contains** | Field value does not include the text            |
| **Starts with**  | Field value begins with the specified text       |
| **Ends with**    | Field value ends with the specified text         |

Numeric fields (custom fields) [#numeric-fields-custom-fields]

| Operator                   | Matches when...                          |
| -------------------------- | ---------------------------------------- |
| **Equals**                 | Field value exactly matches the number   |
| **Not equals**             | Field value does not match               |
| **Greater than**           | Field value is above the threshold       |
| **Greater than or equals** | Field value is at or above the threshold |
| **Less than**              | Field value is below the threshold       |
| **Less than or equals**    | Field value is at or below the threshold |

Tag fields [#tag-fields]

| Operator             | Matches when...                                         |
| -------------------- | ------------------------------------------------------- |
| **Contains any**     | At least one of the specified tags is present           |
| **Contains all**     | All of the specified tags are present                   |
| **Not contains any** | None of the specified tags are present                  |
| **Not contains all** | Not all of the specified tags are present (some may be) |

Presence [#presence]

| Operator           | Matches when...                             |
| ------------------ | ------------------------------------------- |
| **Is present**     | The field has any value (not empty or null) |
| **Is not present** | The field is empty or null                  |

Setting up conditions [#setting-up-conditions]

1. Open your workflow and go to the **Conditions** section
2. Add conditions to the appropriate logic group (all of, any of, none of)
3. For each condition, select the field, operator, and value
4. Conditions are saved automatically as you edit

Leave conditions empty if the workflow should match any ticket — the classification step (based on the "when to use" description) still controls whether the workflow fires.

Conditions vs. "When to use" [#conditions-vs-when-to-use]

These serve different purposes:

|                  | Conditions                                                  | "When to use"                                 |
| ---------------- | ----------------------------------------------------------- | --------------------------------------------- |
| **How it works** | Deterministic field matching                                | AI classification based on description        |
| **When it runs** | Before classification                                       | During classification                         |
| **Use for**      | Hard requirements (must be this status, must have this tag) | Soft matching (ticket topic, customer intent) |

Use conditions for absolute requirements ("only run on open tickets in the email channel") and "when to use" for intent matching ("customer asking about order status").

Common patterns [#common-patterns]

**Channel-specific workflows:**

* All of: Channel equals "chat"
* Ensures the workflow only generates responses appropriate for live chat (shorter, more conversational)

**Priority routing:**

* None of: Priority equals "urgent"
* Skips the workflow for urgent tickets, letting agents handle them directly

**Tag-based activation:**

* Any of: Tags contain any \["billing", "payment", "invoice"]
* Fires for any billing-related ticket regardless of exact wording

**VIP exclusion:**

* None of: Tags contain any \["vip", "enterprise"]
* Routes VIP customers to human agents instead of automated responses

**Custom field filtering:**

* All of: Custom field "order\_value" greater than 500
* Only handles high-value orders with this workflow (useful paired with [escalation rules](/response-workflows/escalation-rules))

Tips [#tips]

* **Start broad, then narrow.** Begin with no conditions and use the "when to use" description for matching. Add conditions once you identify specific cases that need filtering.
* **Combine conditions with escalation rules.** Conditions prevent a workflow from running at all. Escalation rules let the workflow run but prevent it from responding if certain criteria are met. Use conditions for coarse filtering and escalation rules for fine-grained safety checks.
* **Test your conditions.** Use the test panel with different ticket IDs to verify your conditions match the right tickets and exclude the wrong ones.

Related [#related]

* [Actions](/response-workflows/actions)
* [Escalation Rules](/response-workflows/escalation-rules)
* [Creating a Workflow](/response-workflows/creating-a-workflow)