Automations
Automations let you react to things happening in your server without lifting a finger. A rule watches for a trigger, checks any conditions you set, and then runs an action. Everything lives under one section in the dashboard: Automations.
Where it lives
Open the dashboard sidebar and pick Automations. The hub holds your Rules, Flows, Connections, and the run Logs. You need a Manager role (the Manage Automations permission) to use it.
What a rule is
Every rule reads the same way: when a trigger fires, only if the conditions match, then run an action.
Triggers
Pick one of three sources when you build a rule.
Ticket event
Something happens in a ticket: it is created, claimed, closed, a rating comes in, the priority changes, or it goes quiet for a while.
Connected app
A connected app such as Whop or Stripe sends an event, like a new member or a failed payment.
Schedule
Run a flow on a recurring schedule or at a set time, with no ticket involved.
Ticket events
| Event | Fires when |
|---|---|
| Ticket created | A new ticket opens |
| Staff first reply | A staff member replies for the first time |
| Ticket claimed | A staff member claims the ticket |
| Ticket closed | The ticket is closed |
| Creator left | The person who opened it leaves the server |
| Rating submitted | The user leaves a rating |
| Priority changed | The ticket priority is changed |
| Customer first message | The customer sends their first message in a ticket |
| On every user message | The user posts a message (needs a category) |
| After user inactivity | The ticket is waiting on the user and they have not replied since staff last did |
| After staff inactivity | The ticket is waiting on staff and nobody has replied since the user's last message |
| After no activity from either side | Nobody at all has posted for a set number of minutes |
| Time since opened | The ticket has been open for a set number of minutes |
The four time-based triggers ask for a minute threshold, with quick presets for 1, 6, 12, and 24 hours. They can run once per ticket or repeat each cycle when the action supports repeating. On every user message fires on each message and has no run-mode toggle or minute threshold.
Inactivity follows whose turn it is
The two inactivity triggers only fire against the side that owes a reply, and count from the other side's last message. A customer who answered and is now waiting on you is not inactive, however long they wait, so an auto-close rule on after user inactivity cannot shut a ticket out from under them.
That leaves tickets both sides dropped, which no turn-aware rule will ever catch. After no activity from either side is the backstop for those: it ignores whose turn it is and counts from the last message by anyone. Pair a long threshold on it with a shorter after user inactivity rule.
Exempting a single ticket
Rules apply to every ticket in scope, which is a problem when one ticket needs to be left alone: a reference thread you keep around, or one that is waiting on someone outside your team. Staff can pause a single ticket with /pause in its channel, or from the Automations section of the ticket sidebar in the dashboard. Pick 1 hour, 1 day, 1 week, or pause indefinitely.
While a ticket is paused, no rule touches it at all. Not the time-based ones, so it is neither auto-closed nor sent inactivity reminders, and not the event-driven ones like Rating submitted or an AI reply on a customer message. Staff can still close, claim and reply to it by hand. The bot pins a notice in the channel for as long as the pause lasts.
You can also pause and resume from inside an automation: the Pause Automations flow node, or the Stop automations on the ticket rule action. That lets a ticket exempt itself: for example, a flow that reacts to a staff member marking a ticket as "waiting on the customer". Both take a custom length as well as the presets, so a rule can pause for 45 days if that is what you need.
When a pause ends, whether it expires or you run /resume, any inactivity clock restarts from that moment. A ticket paused for a week past a 72-hour rule is not closed the second the pause lapses; it gets the full window again.
Customer first message fires once, when the customer sends their first message in a ticket. Pair it with the Reply with an AI response action to greet a new ticket with a grounded answer before staff pick it up. If you just want a first reply with no rule to build, the AI Control page has a one-click toggle for it.
Member events
| Event | Fires when |
|---|---|
| Member joined | Someone new joins your server |
A Member joined rule opens a welcome ticket for the new member. Set the action to Open a ticket and pick a category; the ticket is owned by the member who joined. Greet them with the category's intro message, or pair it with a Ticket created rule for anything more involved. Bot accounts are ignored, and a new welcome ticket is skipped while the member still has one open in that category. Member-join rules don't take conditions.
Connected-app events
Connect an app on the Connections page first, then pick it when you build the rule. The available events come from that app. See Inbound Triggers for the full list per app.
Conditions
Conditions are optional. Leave them empty and the rule runs every time the trigger fires. Add one or more to narrow it down, then choose whether all of them or any of them must match.
The available checks depend on the trigger source:
| Condition | Ticket events | Connected-app events |
|---|---|---|
What is checked | The ticket itself | The event payload |
Example fields | Message text, ticket age, rating | Any path like data.status |
Operators | Greater than, less than, equals | Equals, contains, is present |
Message text needs a trigger that carries a message
The message contains check is only offered on triggers that fire with a message in hand: on every user message, customer first message, and staff first reply. On any other trigger there is no message to read, so the condition could only ever be false and would kill the rule silently. Saving that combination is rejected. To match on wording elsewhere, use ticket content contains, which reads the ticket's opening content.
Actions
| Action | What it does |
|---|---|
| Run a flow | Hands off to a Support Flow for anything more involved |
| Send a message | Posts a message in the ticket |
| Send to a channel | Posts a message in a channel you pick |
| Close ticket | Closes the ticket, with an optional reason |
| Move category | Moves the ticket to another category |
| Open a ticket | Opens a new ticket (connected-app and member-join rules) |
| Reply with an AI response | Drafts and posts an AI reply in the ticket (Pro) |
The Reply with an AI response action needs the Pro plan with AI nodes enabled (aiNodesAllowed). It can ground its answer in your knowledge base, and run in send mode (posts to the customer) or draft mode (posts a private, staff-only suggestion with Send, Edit, and Discard buttons so a human approves it first). See AI Assist for how grounding and draft mode work.
For connected-app rules you can also map payload fields onto the message or ticket. Each mapping is a label plus a path, so "Plan" with path data.plan shows up as "Plan: Pro".
When to reach for a flow
Rules cover the common "when this, do that" cases on their own. If you need branching, inputs, or several steps in a row, set the action to Run a flow and build the rest in Support Flows.
Ordering and toggles
Ticket-event rules run in priority order, highest first. Use the up and down arrows on each rule to reorder them. Every rule has an on or off switch, so you can pause one without deleting it.
The run log
Every time a rule runs it is recorded in Logs, marked succeeded, skipped, or errored, with a timestamp. The most recent result also shows on each rule in the list. A skipped run usually means the conditions did not match, and an errored run shows what went wrong.
Connected-app rules need Pro
Rules with a ticket-event trigger work on every plan. Rules that react to a connected app are part of Integrations and need the Pro plan, plus a connected app that sends events.
Related
- Inbound Triggers: connected-app events in depth
- Using Support Flows: multi-step automation
- AI Assist: summarize tickets and draft grounded replies
- AI Control: the first-message toggle, usage, and memory review