Creating & Configuring Workflows
This guide walks through how to create, edit, and activate SOAR workflows in UTMStack.
Accessing the Workflow Editor
Navigate to the SOAR section in the UTMStack sidebar to view all existing workflows. From here you can:
Review the list of built-in workflows that ship with UTMStack
Edit an existing workflow to customize it for your environment
Create a new workflow from scratch
Start with a built-in workflow and modify it instead of building from scratch when possible. Built-in workflows follow proven response patterns.
Workflow Structure
Every SOAR workflow has four components:
Basic Details — Name, description, and active/inactive status
Trigger Conditions — What alert conditions activate the workflow
Execution Target — Which platform and agent will run the actions
Action Flow — The sequence of commands to execute
Step 1: Open the Workflow Editor
Select a workflow from the list and click Edit, or click Create New to start from scratch.
Fill in the basic details:
Workflow name — A descriptive name for the workflow
Description — Clearly state what the workflow does and when it should run
Active/Inactive — Toggle whether the workflow should execute automatically
Step 2: Define Trigger Conditions
Go to the Trigger section and set the criteria that will activate the workflow.
The most common approach is to match on the alert name field, tying the workflow to a specific correlation rule:
| Field | Operator | Value |
|---|---|---|
name | IS | RDP Brute Force Attack |
You can add multiple conditions to narrow when the workflow fires. Conditions are combined with AND logic:
| Field | Operator | Value |
|---|---|---|
name | IS | RDP Brute Force Attack |
adversary.ip | IS_NOT | 10.0.0.1 |
Available filter operators: IS, IS_NOT, IS_ONE_OF, IS_NOT_ONE_OF, CONTAIN, DOES_NOT_CONTAIN, IS_BETWEEN, EXIST, DOES_NOT_EXIST, START_WITH, ENDS_WITH, IS_GREATER_THAN, IS_LESS_THAN_OR_EQUALS.
Prefer mapping triggers to alert names tied to correlation rules. Correlation rules handle the detection logic, while SOAR handles the response.
Step 3: Configure the Execution Target
In the Flow of actions section, configure where the workflow runs.
Platform Selection
Windows — Choose CMD or PowerShell as the shell
Linux (Ubuntu/Debian, RHEL/CentOS, OpenSUSE) — Uses Bash
macOS — Uses Bash
Agent Selection
Default — The workflow runs on the agent associated with the alert source. If the alert was generated by data from
windows-server-2019, the workflow runs on that agent.Specific Agent — Select a specific agent to always run the workflow on, regardless of alert source.
Proxy Agent — Use when the target device cannot host its own agent (firewalls, proxies, network appliances). Select a machine with the UTMStack agent installed that can reach the target device (e.g., via SSH).
When using a proxy agent, confirm that the proxy can connect to the target device. For example, a Linux agent acting as a proxy for a firewall must have SSH access to that firewall.
Step 4: Build the Action Flow
Add actions to the workflow using the workflow builder. You can:
Use built-in action blocks — Select from 73 pre-built action templates (block IP, kill process, disable user, etc.)
Add custom commands — Write your own shell commands with dynamic variable substitution
Each action block generates the appropriate command for the selected platform and shell.
Example action sequence for an RDP brute force response:
Block the attacker's IP via Windows Firewall
Kill the active RDP session
Disable the targeted user account
Custom Commands
To add a custom command, click the Define Custom Action card at the bottom of the action sidebar. In the command editor:
Give the action a name and description
Type the shell command in the terminal-style editor
Press TAB to open the variable picker, which shows:
Automation Variables — User-defined reusable values (referenced as
$[variables.varName])Alert Fields — Alert data placeholders (referenced as
$(field.name))
Click a variable or field to insert it at the cursor position
Custom commands run directly on the endpoint. Verify that commands are safe and appropriate for the target platform before saving.
Step 5: Set Step Execution Logic
For workflows with multiple actions, define how each step relates to the previous one:
| Logic | Shell Operator | Behavior |
|---|---|---|
| Always run | ; | Execute this step regardless of the previous step's outcome |
| Run only if previous succeeds | && | Execute only if the previous step completed successfully |
| Run only if previous fails | ` |
This allows you to create branching response logic — for example, try to block an IP, and if that fails, isolate the host instead.
The workflow builder compiles all actions into a single shell command string joined by these operators. For example:
block_ip_command && disable_user_command || isolate_host_commandStep 6: Review and Save
Before saving:
Review the generated command(s) in the Command Preview panel at the bottom of the action builder
Verify the trigger conditions are specific enough to avoid false activations
Confirm the target agent and platform are correct
Click Update Flow to save the workflow (for edits) or Create to save a new workflow.
Test workflows carefully before setting them to Active in production. An overly broad trigger can cause unintended automated responses across your environment.
Workflow Data Model
Each workflow is stored with the following structure:
| Field | Type | Description |
|---|---|---|
id | integer | Unique workflow ID |
name | string | Workflow name |
description | string | What the workflow does |
conditions | array | Trigger conditions (field, operator, value) |
command | string | Final composed command string |
active | boolean | Whether the workflow runs automatically |
agentPlatform | string | Target platform (windows, ubuntu, centos, rocky, darwin) |
defaultAgent | string/null | Specific agent ID, or null for alert-source agent |
shell | string | Command shell (cmd, powershell, bash) |
excludedAgents | array | Agent IDs excluded from execution |
actions | array | Ordered list of action template references |
systemOwner | boolean | Whether this is a built-in workflow |
Dynamic Variables
Action commands can reference alert fields using $(field.name) syntax. These are replaced with actual values from the triggering alert at execution time.
Common variables:
| Variable | Description | Example Value |
|---|---|---|
$(adversary.ip) | Attacker/source IP address | 192.168.1.100 |
$(adversary.user) | Attacker username | admin |
$(adversary.process) | Suspicious process path | C:\malware.exe |
$(adversary.path) | Malicious file path | /tmp/payload.sh |
$(adversary.service) | Service name | evil-service |
$(adversary.windowsServiceDisplayName) | Windows service display name | Malicious Service |
$(target.user) | Target/victim username | john.doe |
$(target.file) | Target file path | C:\Users\docs\secret.docx |
$(target.applicationname) | Application name | suspicious-app |
$(log.message) | Raw log message content | (full log text) |
$(log.winlogEventDataProcessId) | Windows Event process ID | 4532 |
$(log.winlogEventDataProcessName) | Windows Event process name | keylogger.exe |
$(log.eventCode) | Windows Event code | 4625 |
Variables use dot notation to access nested alert fields. Any field present in the alert object can be referenced as a dynamic variable.
Best Practices
Keep triggers specific — Match on exact alert names rather than broad patterns to prevent unintended automation
Use conditional step logic — Reduce unnecessary command execution by running cleanup steps only when the primary action succeeds
Test before activating — Run workflows manually or in a test environment before enabling automatic execution
Document descriptions — Write clear descriptions so other team members understand what each workflow does
Verify agent connectivity — When using proxy agents, confirm the proxy can reach the target device before activating the workflow