Variables

Anywhere you can type text, you can type {something} and FlaviBot replaces it when the rule runs.

Welcome {user.mention} to {server.name}!

Variable names follow a tree. Everything about the member sits under user. or member., everything about the message under message., and so on, so once you know one, you can guess the rest.

Always available

{user}, {user.mention}, {user.id}, {channel.mention}, {channel.id}, {server.id}.

Triggers with no member behind them (a scheduled rule, a channel event) do not offer the user. family, because there is nobody to name.

From the trigger

Each trigger adds its own. A few examples:

The editor lists the ones your trigger actually provides, so you never have to memorise them. If a variable is offered, it resolves: a name in that list that the bot could not fill would be a bug, not a blank.

A rule that belongs to a group also gets {panel.message_id} / {panel.channel_id} (the panel its own button sits on) and {group.panel_message_id} / {group.panel_channel_id} (the group's primary panel), which is how a rule edits the message its group published.

From earlier steps

{steps.2.value} is the value the second step returned. This is how a counter reaches the message that announces it.

Reshaping a value

A variable gives you what it has, which is not always what you want to read. A delay arrives as 300. A member typed their name in capitals. A message is four paragraphs long and you only want the first line in a log.

Add a transformer after the variable name, separated by a colon:

Hello {user.name:trim:uppercase}
Banned in {steps.3.deferred_seconds:duration}
They said: {message.content:truncate(80):escape}

Transformers apply left to right, so the chain reads in the order it happens. Start typing a colon inside a {token} in any text field and the editor lists them, with an example of what each one does.

Text

Numbers

Dates and durations

Lists

A stored list arrives as its raw form — ["ada", "bob"] — which is almost never what you want in a message.

These also work on a value that is not a stored list: a line-separated or comma-separated text is read as one entry per line or per comma, and a plain value counts as a single entry.

An empty list, a missing variable or a position that does not exist all give you nothing back rather than an error, so pair them with :default when you need a fallback:

The next in line is {vars.queue:nth(0):default(nobody yet)}.

\n in a transformer's value is a line break, so a list can go out one entry per line, or as a bulleted list:

Suggestions so far:
{vars.suggestions:join(\n):default(none yet)}

- {vars.suggestions:join(\n- )}

Posting a whole list into a message can get long — Discord cuts a message off at 2000 characters, and an entry someone typed can contain a mention. {vars.queue:join:truncate(1900):escape} keeps both in check.

Comparing two lists

A Set variable step compares two lists with one of its transforms:

The step's text is the first list, the transform's field the other one, and both can be variables. To find what two stored lists have in common:

1. Read data: variable wanted, published as a.
2. Read data: variable owned, published as b.
3. Set variable: name common, text {vars.a.value}, transform Keep if in list with {vars.b.value}.
4. Send message, run only if {vars.common.value:count} is over 0:

Already yours: {vars.common.value:join}

Both sides are read like the list transformers above read a value: a stored list, or one entry per line or per comma. Entries are compared without their surrounding spaces, and Ignore case makes Apple and apple the same entry. The result keeps the first list's order, lists each entry once, and is itself a list, so :join, :count and :nth work on it and a Store data step can keep it. With nothing left it is []: :count gives 0 and :join gives nothing, so {vars.common.value:join:default(nothing in common)} covers that case in a message.

Picking one at random

Read the list with a Read data step, then use the alias it publishes:

The draw happens once, when the Read data step runs. Every later step and every later condition in that run sees the same entry, so you can check it in a condition and then name it in the message without the two disagreeing.

These four are also the only form that works in a field expecting an id — giving the drawn member a role, for instance. A field like that takes a plain {vars.roster.random} and refuses anything carrying a : transformer.

Safety

Links and JSON built from what a member typed

A value pasted into a link or a piece of JSON has to survive the characters people type. In a link, &, #, ? and spaces end the parameter or cut the address; in JSON, a " ends the string. Add the transformer for the place the value lands:

https://www.google.com/search?q={message.content:encode}
{"title": "{modal.title:json}", "by": "{user.name:json}"}

:json does not add the quotes: write them around the token yourself, as above. For a plain list, one entry per line needs neither (see your own stored values).

:replace takes \n too: {message.content:replace(\n| )} puts a multi-line message on one line. The part before the first | is what it looks for, so the text it looks for cannot itself contain a |.

Deadlines that stay true

A card that says "you have 5 minutes" is wrong a minute later. Discord can render a moment that every reader sees in their own language and timezone, and that keeps counting down on its own:

You will be banned {trigger.timestamp:plus(300):relative}

{trigger.timestamp} is when the rule fired, plus(300) moves it five minutes forward (plus(5m) says the same: s, m, h and d are read as seconds, minutes, hours and days), and relative renders it as a live countdown. The same chain with :datetime writes an absolute date instead. Automated messages take the same {trigger.timestamp}, the moment they are sent: {trigger.timestamp:plus(20m):time} is the time twenty minutes later.

A transformer you did not write is left alone

Exactly like an unknown variable: {user.name:shout} stays as typed, and the editor underlines it, rather than posting the value with the formatting silently dropped.

Your own stored values

The data store keeps values between runs: they survive restarts, and they are per server.

• Scope: guild (one value for the server), member (one per member), channel, or group (one per workflow group, shared by its rules and invisible to the rest of the server)
• Type: text, number, boolean, list or JSON
• Expiry: optional; a strike that fades after 30 days is just a counter with an expiry

Read one into a variable and use it: {vars.<name>.value}, plus {vars.<name>.exists} and, for lists, {vars.<name>.length}.

The value field takes several lines. A text keeps its line breaks, and a list is written one entry per line, with no quotes to get right even when the entry is something a member typed. To grow a list, Add to list appends one entry at a time. Store data can also rebuild one: a list read with a Read data step, like {vars.old}, adds all of its entries when it sits on a line of its own, so

{vars.old}
{modal.suggestion}

stores the old list with the new entry at the end, and swapping the two lines puts it first. A list keeps its first 100 entries.

A suggestion box, step by step

A button opens a form with one field, suggestion; every answer joins a list, and the whole list is posted in a thread:

1. Add to list: variable suggestions, value {modal.suggestion}. Turn on Skip duplicates to ignore the same answer twice.
2. Read data: variable suggestions, published as list.
3. Send message to the thread (see posting in a thread):

**Suggestions ({vars.list:count})**
- {vars.list:join(\n- ):escape}

Three things that trip people up

• A variable keeps its type. Add to list on a name that already holds text fails with type_mismatch. Delete the variable first, or use a new name.
• Full lists behave differently. Add to list refuses a 101st entry with list_full, so the rule tells you; Store data keeps the first 100 entries and drops the rest without an error. Put the new entry on the first line to keep the newest 100.
• A text built from itself starts empty. Storing {vars.old} then a new line as text writes an empty first line the first time, while old does not exist yet. A list skips empty lines, so prefer the list type.

Counters are atomic: two members clicking at the exact same moment get 4 and 5, never 4 and 4. A missing counter starts at the default you set (usually 0) instead of failing.

An unknown variable is left alone

If you type {user.birthday} and nothing provides it, the text stays exactly as you typed it. It is never silently replaced by an empty string, so a typo is visible instead of quietly producing a broken message.