Workflows
Workflows automate what happens to conversations, so you don’t have to tag/assign/route the same kind of ticket by hand every time. Every workflow has the same shape:
A trigger, a set of conditions (optionally grouped with “and”/“or”), and one or more actions run in order. Managed under Settings → Workflows — creating, editing, reordering, and deleting them is an admin task, but using the ones that exist is everyone’s.
Automatic vs. manual
Section titled “Automatic vs. manual”- Automatic workflows run themselves — when a conversation arrives or changes, plus once an hour for anything based purely on elapsed time.
- Manual workflows don’t run on their own. You apply one deliberately, to conversations you’ve selected in the list view, via the bulk-actions bar’s Workflow dropdown (“Run manual workflow”).
Either type also has an Apply to mailbox button on Settings → Workflows, next to Clone and Delete. It backfills the workflow against every open conversation already in its mailbox — not just ones that arrive or change from here on — which is the way to retroactively apply a rule you just wrote or edited. It runs in the background, so affected conversations update in the list view as it works through them rather than all at once. Before you start, the dialog performs a dry run and shows how many open tickets are candidates and how many currently match. Once started, keep the dialog open (or reopen it later) to see queued/running progress, succeeded/skipped/failed totals, and links to tickets whose actions failed. Repeated clicks reuse the active run instead of starting duplicates.
The run snapshots its ticket boundary when you click Apply. Tickets created after that point are left for the workflow’s normal future triggers. Large mailboxes are processed in durable batches, so a server restart resumes from the last checkpoint.
A Triggered by condition only matches lifecycle events such as a new conversation or reply. A mailbox-wide application is manual, so condition groups containing Triggered by won’t match; the confirmation dialog calls this out before you start.
Triggers (automatic only)
Section titled “Triggers (automatic only)”Conversation created (by customer or by a user), customer replied, user replied, note added, status changed, assignee changed, moved, customer changed — plus the hourly time-based recheck mentioned above. There’s no “tag added” trigger; tags are something you filter on, not something you react to directly.
Conditions
Section titled “Conditions”Grouped by what they look at:
- Conversation — Subject, Body, From, To, Cc, Has attachments, Conversation type, Status, Assignee, Tag
- Customer — Customer email, Customer name
- Timing — Created, Waiting since, Since last agent reply, Since last customer reply
Each has operators appropriate to its type — contains / doesn’t contain / is / is not / starts with / ends with / matches regex / is more than / is less than.
Actions
Section titled “Actions”Assign to user, Change status, Move to mailbox, Add tag, Remove tag, Send
reply, Add a note, Forward, Mark as spam, Delete conversation, and Stop
processing rules. They run top to bottom — put Stop processing rules
last, or the editor will warn you. Send reply and Add a note both accept
template variables: {%customer.first_name%}, {%customer.full_name%},
{%mailbox.name%}, {%conversation.number%}.
Forward takes one fixed email address, set on the action itself — there’s no template variable and no message field for it. It creates the same kind of new, cross-linked ticket as forwarding by hand (see Forwarding a conversation), always with the original’s attachments included and a generic “Forwarded by workflow” note in place of a custom message.
If you imported from FreeScout
Section titled “If you imported from FreeScout”Workflows brought in from a FreeScout import always land deactivated — review and turn each one on deliberately rather than trusting an automated translation to have gotten the intent right.