Workflow Automation

Prerequisites: Before reading this guide, we recommend familiarizing yourself with the event system section in Core Concepts, as well as Workflow binding in Bot Management.

Workflows are Monstrum’s visual automation engine. You can use the drag-and-drop editor to build DAG (Directed Acyclic Graph) pipelines, chaining multiple steps into automated workflows.

Overview

Workflows address the following problem: many tasks cannot be completed with a single instruction and instead require multiple steps executed in sequence or conditionally. For example:

Receive an Issue -> Analyze content -> Assign to the appropriate Bot -> Notify relevant people
Periodically check server status -> If abnormal, create an alert -> Wait for manual approval -> Execute remediation
Call multiple APIs in parallel -> Aggregate results -> LLM summarization -> Send report

Workflows orchestrate these steps into a visual DAG, supporting conditional branching, parallel execution, manual approval, loop iteration, and other control flows.

Creating a Workflow

Option 1: From the Bot Detail Page

Navigate to the Bot detail page and select the Workflows tab
Click New Workflow
Enter a name and description
Enter the visual editor

Option 2: From the Workflow List

Workflows associated with each Bot are visible on the Bot management page
Or navigate directly to the Workflow editor URL

Workflow States

State	Description
Draft	Newly created, editable, not executable
Activated	Executable, still editable (changes take effect after saving)
Disabled	Execution paused, definition preserved

Visual Editor

The Workflow editor is a drag-and-drop DAG editor.

Interface Layout

Left panel: Node panel listing all available step types
Center canvas: Drag nodes, draw connections, and build the flow
Right panel: Configuration panel displayed when a node is selected
Top toolbar: Save, activate/disable, execute, undo/redo, settings, history, triggers, export

Basic Operations

Add a node: Drag a node from the left panel onto the canvas
Connect nodes: Drag from a node’s output port to another node’s input port
Configure: Click a node to configure its parameters in the right panel
Delete: Select a node or connection and press the Delete key
Undo/Redo: Ctrl+Z / Ctrl+Y

Validation

The editor automatically validates the Workflow for correctness:

There must be exactly one start node
There must be at least one end node
No cycles (circular connections) are allowed
Resource call nodes must have a Resource selected
Condition nodes must have an expression defined
Approval nodes must have an approval description
LLM call nodes must have a prompt defined

Step Types

Start (START)

The entry node of a Workflow. Every Workflow must have exactly one start node.

End (END)

The exit node of a Workflow. There can be multiple end nodes (different branches converging at different endpoints).

Resource Call (RESOURCE_CALL)

Invokes a tool on a Resource, or delegates a task to a Bot.

Configuration:

Field	Description
Step name	Unique identifier within the Workflow
Resource	Select a Resource or Bot
Tool	Select the tool to execute
Tool parameters	Parameters in JSON format, supports variable references
Timeout	Step timeout (seconds)
Max retries	Number of retries on failure

Condition (CONDITION)

Branches execution based on an expression result. Supports two modes:

Boolean (True/False):

Configure a condition expression
If true, take the “Yes” branch
If false, take the “No” branch

Multi-branch (Switch):

Configure a branch value and multiple branch labels
Match the branch value against labels and take the corresponding branch

Condition expressions support referencing output variables from upstream steps:

${check_status.output.status} == "critical"
${analyze.output.score} > 80
${fetch_data.output.count} > 0

Condition expressions use a safe evaluation engine and do not support arbitrary code execution.

Parallel (PARALLEL)

Executes multiple branches simultaneously.

Default is Fail-Fast: if any branch fails, all other branches are immediately cancelled
Fail-Fast can be disabled to allow execution to continue after partial branch failures

Draw multiple connections from a parallel node — each connection represents a parallel branch.

Wait (WAIT)

Pauses execution for a specified duration.

Configuration:

Wait duration: Fixed wait time in seconds
Wait until: Wait until a specific point in time

Approval (APPROVAL)

Pauses Workflow execution and waits for manual approval.

Configuration:

Field	Description
Approval description	Describes what needs to be approved
Notification gateway	Select the Gateway used to send the approval notification
Channel ID	The IM channel where the notification is sent
Timeout	Auto-reject on timeout (0 = no limit)

The approval notification is sent to the specified IM channel, and the approver can approve or reject by replying in the channel.

LLM Call (LLM_CALL)

A single LLM invocation without tool execution. Suitable for text analysis, summary generation, classification, and similar scenarios.

Configuration:

Field	Description
Prompt	Prompt template, supports variable references
System prompt	Optional system instructions
Model	Override the workspace default model
Temperature	Controls randomness
Max tokens	Output token limit
Response format	Optional JSON format constraint

For Each (FOR_EACH)

Iterates over a collection and executes the loop body for each element.

Configuration:

Collection: Reference an array from an upstream step’s output, e.g. ${fetch.output.items}
Loop variable name: Variable name used to reference the current element within the loop body

Sub-Workflow (SUB_WORKFLOW)

Invokes another activated Workflow as a sub-step.

Configuration:

Target Workflow: Select an activated Workflow
Input parameters: Parameters passed to the sub-Workflow

Variable Passing

Steps pass data to each other through variables. Each step’s output can be referenced by downstream steps.

Reference Syntax

${step_name.output.field_name}

Examples:

${check_server.output.status} — References the status field from the check_server step’s output
${fetch_data.output.items[0].name} — References an array element

Using Variables in Tool Parameters

Resource call step tool parameters support variable references:

{
  "command": "systemctl restart ${analyze.output.service_name}",
  "host": "${get_target.output.host}"
}

Using Variables in Prompts

LLM call step prompt templates support variable references:

Please analyze the following server status report:
${check_status.output.report}

And provide recommendations.

Available Variables Panel

When a step is selected in the editor, you can view the list of variables available to that step (from upstream step outputs). Click a variable name to copy its reference syntax.

Workflow Settings

Click the Settings button at the top of the editor to configure global Workflow settings:

Setting	Description
Max execution time	Overall Workflow timeout (seconds). Individual step timeouts cannot exceed the remaining budget
Retry on failure	Whether to enable automatic retries
Max retries	Global retry count limit
Tags	Workflow tags for categorization and filtering

Trigger Methods

Workflows support 4 trigger methods:

Manual Trigger

Click the Execute button in the editor, or click execute in the Workflow list.

Scheduled Trigger

Trigger Workflow execution via Scheduled Tasks. When creating a schedule, select “Workflow” as the target type and choose the Workflow to trigger.

Event Trigger

Automatically execute via event triggers.

Click the Triggers button in the editor
Click Add Trigger
Configure:
- Event pattern: fnmatch pattern, e.g. task.completed, workflow.*, schedule.fired
- Instruction: Context information passed to the Workflow (optional)
- Enabled: Whether this trigger is active
Save

Common event patterns:

Event Pattern	Trigger Condition
`task.completed`	When a task completes
`task.failed`	When a task fails
`workflow.completed`	When a Workflow completes
`schedule.fired`	When a scheduled task fires
`custom.*`	Custom events published by a Bot

API Trigger

Trigger via API call: POST /api/workflows/{id}/execute.

Binding to a Bot

Workflows can be bound to a Bot, allowing the Bot to use Workflows during conversations.

In the Bot detail page under the Workflows tab, set the binding mode for each Workflow:

Binding Mode	Description
Unbound	Bot cannot use this Workflow
AI Auto	Workflow is injected as an LLM tool; the Bot autonomously decides whether to invoke it based on conversation context
Command	User triggers it by entering a specific command in the conversation (requires configuring a command name, e.g. `deploy`)
Auto + Command	Both methods are supported

You can also configure command permissions: Admin only or Everyone.

Execution History

Viewing Execution History

Click the History button in the editor to view all execution records for the Workflow:

Execution status
Trigger method (manual / scheduled / event trigger / API)
Duration
Creation time

Execution Details

Click an execution to view its details:

Execution status and duration for each step
Input parameters and output results for each step
Error messages for failed steps
Approval results for approval steps

Execution Statistics

The top of the editor displays Workflow statistics:

Success rate
Total executions
Average duration
Slowest step

Execution States

State	Description
Pending	Queued and waiting for execution
Running	Currently executing
Succeeded	All steps completed successfully
Failed	A step failed during execution
Cancelled	Manually cancelled
Timed out	Exceeded the maximum execution time
Awaiting approval	Paused at an approval step

Import and Export

Export

Click the Export button in the editor to export the Workflow as a JSON file. The export includes all step definitions, connections, and configurations.

Import

Click Import in the Workflow list
Upload a Workflow JSON file
In the dependency mapping, map external dependencies (Resource IDs, Bot IDs) to local resources
Select the owning Bot
Confirm the import

Security Mechanisms

The Workflow execution engine has multiple built-in security layers:

DAG cycle detection: Automatically detects circular connections on save, preventing infinite execution
Timeout budget: Global timeout limit + per-step timeout capped at the remaining budget, preventing a single step from exhausting the entire Workflow
Parallel Fail-Fast: Any failure in a parallel branch immediately cancels sibling branches (can be disabled)
Safe expressions: Condition expressions use AST-allowlist evaluation and do not support arbitrary code execution
Permission checks: Resource call steps go through the full permission check pipeline

Common Use Cases

Automated Operations Pipeline

Start -> Check server status (SSH) -> Condition
  |-- Normal -> Log result -> End
  |-- Abnormal -> LLM analysis -> Approval -> Execute fix -> Notify -> End

Data Processing Pipeline

Start -> Fetch data (API) -> Parallel processing
  |-- Branch 1: Data cleansing
  |-- Branch 2: Data analysis
  |-- Branch 3: Data backup
-> Aggregate results -> LLM summary -> Send report -> End

Event-Driven Response

Set up a trigger to listen for task.failed events and automatically execute a fault analysis and notification pipeline.

FAQ

”Cycle detected” error when saving the Workflow

Check whether connections form a loop. Use the editor’s validation feature to locate the problematic connections.

A step timed out but the Workflow is still running

Each step’s timeout is constrained by the global timeout budget. If the global timeout has sufficient remaining time, a step timeout only affects that individual step. Check the maximum execution time in the Workflow settings.

Condition expression not working

Confirm that the expression syntax is correct and that the variable references match the actual step names. Check whether the upstream step’s output contains the referenced fields.

Not receiving approval notifications

Check the notification gateway configuration on the approval step
Confirm the Gateway status is healthy
Confirm the channel ID is correct

Edit this page on GitHub