Creating & Configuring Workflows
This guide explains how to create, edit, and activate SOAR workflows in Unified Security Stack.
Accessing the Workflow Editor
Navigate to the SOAR section of the Unified Security Stack sidebar to see every workflow that already exists. From this point, you can:
Review the list of built-in workflows that ship with Unified Security Stack
Edit an existing workflow to customize it for your environment
Create a new workflow from scratch
When you can, begin with a built-in workflow and adjust it rather than creating one from scratch. Built-in workflows use established 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 define the conditions that will trigger 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 limit when the workflow triggers. Conditions are joined using 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.
Whenever possible, map triggers to alert names linked to correlation rules. Correlation rules manage detection logic, and SOAR manages the response.
Step 3: Configure the Execution Target
In the Flow of actions section, specify where the workflow executes.
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 executes on the agent tied to the alert source. If the alert was produced by data from
windows-server-2019, the workflow executes on that agent.Specific Agent — Choose a particular agent on which the workflow always runs, no matter the alert source.
Proxy Agent — Apply this when the target device cannot run its own agent (firewalls, proxies, network appliances). Choose a machine that has the Unified Security Stack agent installed and can reach the target device (for example, over SSH).
If you use a proxy agent, verify that the proxy can reach the target device. For instance, a Linux agent serving as a proxy for a firewall needs SSH access to that firewall.
Step 4: Build the Action Flow
Use the workflow builder to add actions to the workflow. 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
Every action block creates the correct command for the chosen 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 located at the bottom of the action sidebar. Inside 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 execute directly on the endpoint. Before saving, confirm that the commands are safe and suitable for the target platform.
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 lets you build branching response logic — for instance, attempt to block an IP, and if that does not work, isolate the host instead.
The workflow builder combines all actions into one shell command string linked 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. A trigger that is too broad can lead to unintended automated responses throughout 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. At execution time, these are replaced with real values from the alert that triggered the workflow.
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 rely on dot notation to reach nested alert fields. Any field available in the alert object can be used 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