Skip to main content
As your automations grow, you’ll find yourself repeating the same block logic in multiple places. erlc.dev Studio solves this with pages — reusable sub-routines you define once and call anywhere. Alongside pages, broadcasts let separate automations communicate with each other by name, and a rich set of flow control blocks gives you the loops, conditionals, throttles, and error handling you need to build complex, production-ready logic without clutter.

Pages

A page is a self-contained block stack that lives on its own canvas, separate from your main automation stacks. You call a page from any automation using erlc_call_page, and execution returns to the caller once the page finishes. Pages are ideal for logic you reuse in more than one place — moderation checks, message formatters, role verification routines, and similar patterns.
1

Create a page

Open the Pages tab in the left panel and click + New Page. Give the page a descriptive name. A new, empty canvas opens.
2

Add an entry block

Drag an erlc_page_start block onto the page’s canvas. This block marks the beginning of the page’s logic. Everything you want the page to do goes beneath it.
3

Build the page logic

Connect action and value blocks beneath erlc_page_start just as you would in a regular automation. The page can use local variables, call Discord actions, run game commands, and even call other pages.
4

Call the page from an automation

In any automation, drag an erlc_call_page block into your action chain. Use the dropdown on the block to select the page you created. When the automation runs and reaches erlc_call_page, it executes the entire page before moving to the next block.
Pages share the same local variable scope as the automation that calls them. A variable set before erlc_call_page is readable inside the page, and a variable set inside the page is readable after the call returns.
Name your pages with a verb that describes what they do: Check_Player_Permissions, Send_Warning_DM, Format_Join_Embed. This makes erlc_call_page dropdowns easy to navigate at a glance.

Broadcasts

Broadcasts are Studio’s inter-automation messaging system. One automation fires a named signal — optionally with a data payload — and any automation whose entry block is erlc_when_broadcast and whose name matches the signal immediately begins its run.

erlc_broadcast

Fires a named broadcast signal with no payload. Any erlc_when_broadcast listening for that exact name begins executing.

erlc_broadcast_value

Fires a named broadcast signal and attaches a data payload. The receiving automation can read the payload with erlc_received_message_value.

erlc_when_broadcast

Entry block that listens for a named broadcast signal. Set the name field to match the name used in erlc_broadcast or erlc_broadcast_value.

erlc_received_message_name

Value block — returns the name of the broadcast signal that triggered the current erlc_when_broadcast run.

erlc_received_message_value

Value block — returns the data payload attached to the broadcast. Use it anywhere you need the data the sender included via erlc_broadcast_value.

Broadcast example

Say you have a moderation automation that detects a rule violation. Rather than placing all notification logic in one giant stack, you fire a broadcast and let a dedicated notification automation handle it: Sender automation (triggered by erlc_when_event):
Receiver automation (triggered by erlc_when_broadcast with name player_warned):
When the sender fires, the receiver’s log block outputs the warned player’s name.
Broadcast names are case-sensitive. Player_Warned and player_warned are treated as different signals. Establish a naming convention (e.g. all lowercase with underscores) and use it consistently.

Flow Control Blocks

Flow control blocks let you branch, loop, pause, and manage errors inside your automations. All flow control blocks are action blocks — they sit in the vertical chain and execute in order.

Conditionals

Executes its inner block stack only when the condition value evaluates to true. If the condition is false, the inner stack is skipped and execution continues with the next block after erlc_if_then.
Like erlc_if_then, but provides a second inner stack — the else branch — that executes when the condition is false. Use this when you need two distinct code paths.

Loops

erlc_while

Repeats its inner stack as long as the condition remains true. Evaluates the condition before each iteration — if false on the first check, the inner stack never runs.

erlc_repeat

Repeats its inner stack a fixed number of times. Provide the count as a number value.

erlc_repeat_for_seconds

Repeats its inner stack as rapidly as possible for a specified number of seconds, then continues.

erlc_repeat_until

Repeats its inner stack until the condition evaluates to true. Evaluates after each iteration — the inner stack always runs at least once.

erlc_for_each

Iterates over every item in a list. Exposes the current item as a named variable for the inner stack to use on each iteration.

erlc_forever

Repeats its inner stack indefinitely. Has no next connector — no blocks can be placed after it in the same stack. Use erlc_stop_run or erlc_break_loop inside the inner stack to exit.

Loop control

erlc_break_loop

Immediately exits the nearest enclosing loop (erlc_while, erlc_repeat, erlc_for_each, erlc_forever, etc.) and continues with whatever comes after the loop block.

erlc_continue_loop

Skips the remainder of the current loop iteration and jumps back to the top for the next iteration.

Stopping execution

erlc_stop_run

Stops the entire automation run immediately. No further blocks in any stack execute. Use this for hard exits when an unrecoverable condition is detected.

erlc_stop_stack

Stops the current block stack only. If this block is inside an erlc_if_then inner stack, for example, the outer automation continues after the erlc_if_then block.

Timing blocks

erlc_wait

Pauses execution for a specified number of seconds. The automation resumes automatically from the next block after the wait expires.

erlc_wait_until

Pauses execution and polls the condition repeatedly until it evaluates to true, then continues. Useful for waiting on an external state change.
Avoid very long erlc_wait durations or erlc_wait_until loops with slow-changing conditions inside erlc_forever blocks — these can keep an automation alive indefinitely and consume run resources.

Rate limiting and deduplication

erlc_throttle

Wraps an inner block of code and ensures it can only execute once within a given time window. Subsequent calls within the window are silently skipped. Essential for preventing spam when an event fires rapidly.

erlc_run_once

Wraps an inner block of code and executes it only on the first call for a given key. All subsequent calls with the same key are skipped — even across different runs. Use this for one-time setup logic.

Error handling

Wraps a block of logic in a try/catch structure. The try inner stack executes normally. If any block inside it throws a runtime error, execution immediately jumps to the catch inner stack instead. Use erlc_log in the catch stack to record what went wrong.
Wrap any Discord API action that could fail due to permissions (ban, kick, role assignment) in erlc_try_catch. Log the error in the catch block so you can diagnose it without the whole automation silently dying.

Flow control quick reference