Skip to content
Qreate

Browse documentation

Search documentation

Suggested guides

Automations

Build simple if-this-then-that rules that connect modules, roles, messages, and staff workflows.

On this page

Build simple if-this-then-that rules that connect modules, roles, messages, and staff workflows.

Set it up

  1. Open Automations and enable it.
  2. Create a rule with one trigger, optional conditions, and one or more actions.
  3. Turn on a staff-only log action, save, and test the rule with a harmless case before using it live.

How to think about automations

An automation is a small rule: when this trigger happens, optionally check conditions, then run one or more actions. Keep the first rule narrow, test it, then add more rules.

Supported rule shape

  • Trigger - the event that starts the rule, such as a member joining, verification passing, a role being granted, or a scheduled interval.
  • Conditions - optional checks, such as member has/does not have a role, channel matches, or text contains a phrase.
  • Actions - what Qreate does next, such as grant/remove a role, send a message, post a log, or open a follow-up workflow.

Messages a rule sends

A send-message or send-DM action takes plain text, an embed, or both. Tick Add an embed on the action and you get the same editor as welcome messages, scheduled posts and reminders: title, description, colour, images from QAssets, fields and a footer. The {user}, {user.name}, {server} and {memberCount} placeholders work inside the embed too.

{user} pings the member even inside the embed: Qreate repeats the mention in the message text, because Discord never notifies anyone for a mention that only sits in an embed. A mention you type out by hand inside an embed does not ping.

Example rules

text
New member onboarding:
Trigger: member joins
Conditions: account age greater than 7 days
Actions: send welcome DM, add @New role, post to #mod-log

Verified reward:
Trigger: verification passed
Conditions: member does not have @Member
Actions: add @Member, remove @New, post a short welcome in #welcome

Support escalation:
Trigger: ticket created
Conditions: category is Billing
Actions: mention @Support Lead, add internal note, route log to #ticket-log

Safety rules

  • Do not build loops where an action immediately retriggers the same rule.
  • For role actions, check Qreate's role hierarchy before enabling the rule.
  • Use a staff-only log action while testing so you can see each run.
  • Disable or pause a noisy rule before editing it during a live event.

What to know

  • Automations is for glue between existing surfaces, not a replacement for module settings.
  • A rule can now react to a ticket moving, not only to one opening or closing. The Ticket moves trigger fires when a ticket changes stage, forum tag, priority or assignee, and it fires once per change: saving a ticket twice does not run the rule twice.
  • Narrow it with Ticket moved into, for example a stage you named yourself such as Deploying Feature. Your stage list lives in the Tickets settings, and a server that has not named any stages sees no stage button on its tickets.
  • Summarise the whole ticket reads the entire thread, including replies your staff sent from the dashboard, and works out what the person asked for, what was actually built, and how to try it. Those three become variables that a later action in the same rule can put into a message.
  • Draw a picture produces artwork from a description and hands the later actions its address, so a post can look different each time instead of reusing one uploaded image. It counts against your server's picture allowance, the same as drawing one yourself. Drawing pictures is part of the paid plans.
  • Remember something on the ticket is how a rule avoids repeating itself. Check that the ticket does not yet remember a key, do the work, then set it. That is what stops the same person being thanked twice when the ticket moves again.
  • Any action can be set to wait for approval. Qreate then stops, posts the finished preview into a channel you choose with Approve and Reject, and runs the rest of the rule only once somebody approves. The pause covers everything after that point, so what you read in the preview is exactly what goes out. If two people approve at the same moment it still posts once.
  • Keep rules small and named by outcome, such as Verified member cleanup or Billing ticket escalation.
  • If a rule grants or removes roles, Discord role hierarchy still applies.
  • A rule that posts a message needs somewhere to post it: either a fixed channel, or Reply where the trigger happened, which answers in the channel the message came from. That second option is what a rule that replies to people wants, because a fixed channel would answer the question somewhere the person who asked is not looking. A rule with neither is refused when you save it, and told why.
  • A Send message rule says the same thing to every question, and a follow-up that does not repeat the trigger words matches nothing. If you want the bot to actually reply, use the Answer with Q action instead: it answers the person in the channel they asked in, and it can see the last few messages, so "what about verification?" works as a follow-up. Q answers each person at a measured pace, and each answer uses part of your plan's AI allowance.

Next steps