Workflows
Workflows automate what happens in CyberGuard. A workflow reacts to something — a schedule firing, an object changing, an external system calling in, or you pressing a button — then runs a series of steps: read objects, create or update them, branch on a value, loop over a list, send an email, call an external system. You build them visually on a canvas, no code involved, and everything a workflow does is bounded by the permissions of the person who published it.
Where to find it
Section titled “Where to find it”Operations → Workflows lists every workflow you can see, with its triggers, activity and domain. The + button creates one, the import button next to it imports an exported workflow file, and opening a workflow lands you in the builder.
The builder
Section titled “The builder”A workflow is a graph of steps connected by wires. The left palette offers what you can place; select a step and the right-hand inspector shows its settings. Steps exchange data through expressions such as {{today}} or {{nodes.past_their_eta.count}} — the inspector’s Available data browser lets you click real values from a previous run to insert the right expression. Variables hold named values a run can set and compare; secrets store credentials for HTTP calls, write-only and scoped to one workflow. Every change autosaves; Undo and Redo cover fifty steps of history.
Triggers
Section titled “Triggers”A run starts at a trigger step:
| Trigger | Starts a run when |
|---|---|
| Manual | Someone clicks Execute |
| Webhook | An external system posts JSON to the trigger’s URL |
| Schedule | A cron expression fires |
| On event | An object is created, updated or deleted in CyberGuard |
| Step | Does |
|---|---|
| Condition | Picks exactly one branch based on variable values |
| Action | Does one thing — read, create, update, email, HTTP request |
| Loop | Runs its body once per item of a list or paged read |
| Stop run | Ends the whole run immediately |
Where a step has several outgoing wires, all of them run in parallel; use a Condition when you want exactly one path.
Publishing
Section titled “Publishing”A workflow has at most one draft and one published version at a time; older published versions are archived. Publish runs a set of checks (problems appear as a clickable list, one line per issue), freezes the graph, registers the triggers and stamps you as the version’s run identity — every run executes as the person who published it, with their permissions checked live at each step. Editing a published workflow silently creates a new draft; the published version keeps running until you publish or discard the draft. The Enabled / Disabled switch in the header pauses all automatic triggers while keeping manual runs working for debugging.
A run is one execution of one version, with a status of Active, Completed or Failed. The Runs panel keeps every run’s variables, starting payload, per-step output and log; Show on canvas paints a run over the graph — visited wires turn green, a failed step gets a red ring — and Replay steps through it at a readable pace.
Related
Section titled “Related”- Applied controls — a favourite automation target (overdue-ETA digests).
- Incidents — react to new incidents with follow-up actions.
- Tasks — recurring human work; workflows handle the recurring machine work.