Automations
When this happens, do that — set up once, runs itself
Automations follow the pattern "when this happens, do that" — pick a trigger, add any conditions, then build a branching chain of actions. It's the same engine that powers custom commands and moderation presets under the hood, just exposed directly for anything that isn't already covered by a dedicated module.
Turning it on or off
Every server chooses for itself — switch Automations on or off from your dashboard, under Messages & Automation. When it's off: none of your automations will run.
Setting it up
- 1
Start from a recipe
The dashboard ships working examples — a boost thank-you, auto-archiving stale tickets, a welcome DM plus role, a level-20 announcement — copy one and adjust it rather than starting from a blank rule.
- 2
Pick a trigger and narrow it with filters
The more specific the trigger filters, the less you need to rely on the gate to rule out cases you don't want.
- 3
Build the action chain
Start with one or two actions; branching is there for when a flat sequence genuinely isn't enough.
- 4
Test with dry run first
Especially for anything that touches roles, bans, or messages — confirm the logic before it can actually act.
- 5
Set a cooldown and run cap on anything trigger-heavy
Message-sent and reaction-added rules in a busy server can fire very often — cap them explicitly rather than relying on good luck.
Triggers
There are over 20 trigger types covering member joins/leaves/boosts, messages sent/edited/deleted, reactions added/removed, voice join/leave/move, roles added/removed, level-ups, tickets opening/closing, form submissions, giveaways ending, invites being used, nickname changes, timeouts expiring, and a plain cron schedule for anything time-based rather than event-based.
Most triggers accept filters — a specific channel, a specific role, a minimum level, a specific form — so a rule only fires for the exact situation you mean, not every occurrence of that trigger type server-wide.
Gates and branching
A top-level gate is a set of conditions that must all pass before the action chain even starts — the automation-wide version of a scope. From there, the action tree can branch: different outcomes depending on conditions checked mid-chain, not just a flat list of steps run in order.
What an action can do
The action library covers sending a message (channel or DM), adding/removing/toggling a role, deleting the triggering message, writing a log line, giving currency or XP, running another command, waiting before continuing, purging a member's recent messages, creating a thread, pinning, crossposting, calling an outside webhook, reacting, renaming, moving between voice channels, disconnecting from voice, slowmode and channel lock changes, an outbound HTTP request (Premium, domain-restricted), the full punishment set (warn/timeout/kick/ban/tempban), and quarantine.
Rate limiting and safety
Every rule has its own cooldown (scoped to the rule overall, per user, or per channel) and a run cap — a maximum number of runs within a time window, so a badly-designed rule can't loop or fire uncontrollably. Dry run lets you test a rule's logic and see what it would have done, without it actually taking any action yet.
Commands
Tips & things people get wrong
- Dry run is the single best way to avoid a rule doing something unintended in production — use it every time you build something non-trivial, not just when you're unsure.
- A cron trigger and a Scheduled Message look similar but solve different problems — reach for Scheduled Messages for "post this text on a timer" and Automations when the timer needs to trigger actions, not just a message.
- The run cap exists specifically to stop a feedback loop (a rule whose own action re-triggers its own trigger) from running away — set one on any rule where that's even theoretically possible.