Workflow Conditions
Overview
Conditions determine whether a workflow's actions should run for a given ticket. You can add multiple conditions to a single workflow and choose how they are evaluated together.
Available condition types
Subject contains
Matches when the ticket's subject line contains any of the specified text values. This is a case-insensitive partial match. For example, adding "invoice" will match subjects like "Question about my invoice" or "Invoice #1234".
Subject equals
Matches when the ticket's subject line exactly equals one of the specified values. Use this when you need precise matching rather than partial text search.
From email contains
Matches when the sender's email address contains any of the specified text values. Useful for matching patterns like "noreply" or a specific username fragment.
From email equals
Matches when the sender's email address exactly equals one of the specified values. Use this for routing tickets from known senders such as "billing@partner.com".
From domain equals
Matches when the sender's email domain exactly equals one of the specified values. Use this to apply special handling for all emails from a particular company, such as "example.com".
To email equals
Matches when the mail was addressed to one of the specified email addresses. A channel can have aliases, so mail arriving on the same channel can carry different recipients. Use this to treat mail sent to info@yourcompany.com differently from the rest of the channel, for example by giving it its own tag.
Only the To header is read, so mail that merely carries the address in Cc does not match. The recipients come from the most recent inbound message, which on a new ticket is the mail the ticket was created from.
To email contains
Matches when one of the addresses the mail was sent to contains any of the specified text values. Use this to match on a fragment such as info@ when the same alias exists on several domains.
Body contains
Matches when the body of the first message in the ticket contains any of the specified text values. Helpful for detecting keywords like "urgent", "refund", or specific product names.
Channel is
Matches when the ticket was received through one of the specified channels. Select one or more channels from your workspace. This is useful when different channels require different handling.
Channel type is
Matches when the ticket was received through a channel of the specified type (email or widget). Use this to apply rules that depend on whether tickets came from email or from the support bubble, regardless of which specific channel they belong to.
Has tag
Matches when the ticket carries any of the selected tags. Select one or more tags from your workspace. Use this to narrow a workflow to tickets that have already been labelled, for example only running an escalation on tickets tagged "urgent".
Does not have tag
Matches when the ticket carries none of the selected tags. Useful as a guard so a workflow skips tickets that have already been handled, for example only auto-replying to tickets that are not tagged "answered".
Contact is new
Matches when the ticket comes from a first-time contact (someone who has never submitted a ticket before). No additional parameters are required. Use this for triggering welcome messages or flagging new customers for special attention.
Is the first message in the ticket
Matches only on the first message of a ticket, not on replies. Useful when a workflow with the On inbound message trigger should still only act on the first message of each ticket. (For workflows that fire only on new tickets, prefer the dedicated On new ticket trigger.)
Is an automatic reply
Matches when the message was generated by a machine rather than typed by a person: an out-of-office notice, a delivery report, or a receipt from another ticketing system. No additional parameters are required.
The match comes first from the headers the sending mail server attaches: Auto-Submitted (RFC 3834), the empty envelope sender that responders use to avoid mail loops, and the older conventions that predate the RFC, such as X-Autoreply, X-Autoresponse and X-MDAutoResponse. Plenty of responders never set one, and some forwarding relays strip them. Where no header survives, the message itself is read by AI as it arrives, which asks whether a system sent it on its own rather than a person choosing to write to you. That works in any language, and on mail that never uses a recognisable phrase at all, so you do not have to list anything yourself.
Pair it with an Add tags and a Set status action to file these away automatically:
- Trigger: On inbound message
- Condition: Is an automatic reply
- Actions: Add tags → "Automatic reply", then Set status → Closed
Use the On inbound message trigger rather than On new ticket. An out-of-office reply to a ticket that already exists reopens it, and only On inbound message sees that.
This is the recommended way to handle out-of-office floods, and it is worth setting up before you send a newsletter or briefing from a channel address. Prefer it over asking a Run AI prompt action to spot them. Every incoming message is already checked as it arrives, so this condition costs you nothing extra to switch on, where an AI prompt is a separate call per reply.
Bounces also count as automatic replies, since a mail server generated them. If you want to treat them separately, use the condition below.
Is a bounce or delivery report
Matches when the message is a mail server reporting on a delivery rather than a person writing to you: a hard bounce, a delay warning, or a rejection notice. No additional parameters are required.
The match comes from the reporting mailbox itself (MAILER-DAEMON, Mailsystem), which is a convention every mail server follows. Anything else is read by AI, which asks whether the message is a mail server reporting on a delivery. A customer writing "Could not deliver my parcel" still reaches you as a normal ticket, and so does mail from a postmaster address, which plenty of companies alias to a real person's inbox.
Neither condition matches a message someone forwarded to you. What counts is whether a system sent the message on its own, not what the message happens to contain, so a customer sending you a copy of a bounce or an out-of-office notice to ask about it is a normal ticket and stays one.
Anything this matches also matches Is an automatic reply, so use this one when bounces need different handling from out-of-office notices. A newsletter sender usually wants to keep bounces long enough to clean the list, while deleting out-of-office replies outright.
Is spam
Matches when the message is unsolicited: cold sales outreach, a marketing blast, a scam, or phishing. No additional parameters are required.
Mail that your provider's own spam filter already flagged is recognised for free. Anything it let through is read by AI as it arrives, in the same pass as the two conditions above, so this costs you nothing extra to switch on.
The most common setup files it out of sight automatically:
- Trigger: On inbound message
- Condition: Is spam
- Action: Set status → Spam
Use the On inbound message trigger rather than On new ticket, so a spam reply to an existing ticket is caught too.
Genuine customer mail is left alone even when it reads like a sales pitch, and a customer forwarding you a piece of spam to ask about it stays a normal ticket. The line is deliberately drawn so that missing a piece of spam is preferred over hiding a real customer, since you can always mark the leftovers by hand.
Combining conditions
When a workflow has multiple conditions, you choose one of two matching modes:
- Match all: Every condition must pass for the workflow to trigger. Use this when you need precise targeting (for example, emails from a specific domain AND containing a keyword).
- Match any: At least one condition must pass. Use this for broader matching (for example, emails containing "billing" OR "payment").