How data flows

An execution starts from an Event and follows the links, node after node. Along the way, it fills a context: what the Event brought, then what each node produced. A node reads from this context with expressions {{ … }}.

Where the data comes from

A node writes its output once it has run, never before.

Some outputs are a code from a fixed list: a departure's reason (kicked), a channel's type (voice), a voice Event's action (moved). Each has its words, in the server's language, right beside it: reasonText (“kick”), typeText (“voice”), actionText (“moved”). Compare the code in a Condition, write the words in a message. The node reference lists what each one writes, output by output, and the properties panel's Output tab shows it in the editor.

What a node can read

A node only reads what ran before it on the path that leads to it. Type {{ in a field: the editor only offers that data, following the Blueprint's links. A node on another branch, or one that comes later, is never offered.

An Action that fails takes its Failure output and only writes success (false) and error: what follows its Failure doesn't find the message it would have sent. error.code says what happened, error.message says it in the server's language (Errors).

"Can be empty"

A value can be missing when a node reads it. The editor colors it orange in the field, in two cases:

• the node that writes it didn't run, or didn't succeed, on every path that leads here: a node linked to both the Success and the Failure of an Action, or one two paths reach while only one goes through the node that writes;
• Discord doesn't always send it: the voice channel of a member who is in none, the category of a channel outside any. The reference's "Nullable" column says so for each field.

An empty value shows as nothing in a text, and makes a required field fail. Give it a fallback: {{ default(events.<id>.member.voiceChannel.name, 'not in voice') }}. The preview under the field, with If empty, shows what that gives.

Several branches

An output linked to several nodes runs them one after the other, in the order shown on its links: the first branch runs to its end, then the second starts. See Add and link Nodes.

Branches don't see each other in the editor: a node of the second can't refer to a node of the first. To pass a value from one to the other, store it in a temporary Variable: the second branch reads what the first wrote there, since it runs afterwards.

What lasts longer

The context is gone when the execution ends. To keep a value from one execution to the next (a member's XP, a counter, the channel picked with /setup), use a server or member Variable: it stays in the database, and it is written as soon as its node runs.

After a wait, the branch resumes with the context from when it stopped: the Event's data is what it was at the start, not what it is now.

An example, end to end

A welcome Blueprint:

1. Member Added starts the execution. It writes events.<id>.member: the new member, with their name, avatar and account creation date.
2. Add to a Variable, on a server Variable arrivals, adds 1. It writes actions.<id>.value, the new value.
3. Send Message in the welcome channel:

   Welcome {{ events.<id>.member.displayName }}! You're arrival number {{ actions.<id>.value }}, out of {{ server.memberCount }} members.
   

   
   It reads the Event (step 1), the Variable (step 2) and the server. It writes actions.<id>.message, the message sent.
4. Add Reaction to that message reads its channel and id from step 3's output: {{ actions.<id>.message.channel.id }} and {{ actions.<id>.message.id }}.

If the bot isn't allowed to write in the channel, step 3 takes its Failure output: the reaction, linked to its Success, doesn't run. A node linked to the Failure can write {{ actions.<id>.error.message }} to a log channel.