How a Flow Works

This page explains the mechanics behind a Flow. It walks through the nodes that form its canvas, the settings the Flow node holds, the rules that limit how actions chain, and how an edit moves from saved to published.

The Flow Canvas

Every Flow is drawn as a graph on a canvas, built from three kinds of nodes:

• Flow node: The root of the Flow. It holds the Flow's name, description, and activation state.
• Trigger node: Defines when the Flow starts. Each Flow has exactly one trigger, and it is always present on the canvas. See Flow Triggers for the six trigger types.
• Action nodes: Define what happens after the trigger activates. Actions run in order, from the trigger through each action node. See Actions for the available action types.

For moving around the canvas, the zoom controls, and opening each node's settings panel, see Navigate the Canvas.

The Flow Node

The Flow node is the root of the graph and the Flow's identity. It exists from the moment the Flow is created, cannot be removed, and everything else on the canvas hangs from it. The name it carries is how the Flow appears on the canvas, on the Flows list, and in the messages its notifications send.

The Deactivated option on this node pauses the Flow. A paused Flow keeps its full configuration and ignores its trigger; it shows greyed out on the Flows list until you activate it again. See Activate or Deactivate a Flow.

Clicking the node opens the Flow Settings panel; each field is described in the Create a Flow field reference.

Chaining Rules

A few rules constrain how action nodes can be chained:

• The canvas accepts at most 10 Operation actions per Flow (Sync, Profile, Scan, Export, Materialize).
• Notification and Workflow actions cannot have child actions. They end their branch, so place them last.
• Ticketing actions are only available after the Anomaly Detected and Anomaly Status Changed triggers.
• Actions that rely on an external service (for example Slack, ticketing systems, or n8n) require the corresponding integration to be connected before they can be selected.

Saving, Publishing, and Unpublished Changes

Edits to a Flow follow a draft-then-publish model:

1. Save on a node's panel stores the edit as an unpublished change. The edited node shows a CHANGED badge next to its name, and the You have unpublished changes banner appears on the canvas.
2. Publish is what actually saves the Flow. It persists every unpublished change at once, makes them live, and clears the badges.
3. Cancel, on the banner, discards the unpublished changes and restores the last published version of the Flow.

If you navigate away while changes are pending, the Unpublished Changes dialog warns that the changes will be lost if you leave the page.

Publish Validation

When you publish, the platform validates the whole Flow. If a node's setup is incomplete (for example a missing name or an unconfigured trigger), the publish fails, the failure dialog lists what is missing, and the affected nodes are marked with a red alert icon.

A notification whose message or subject names a variable the trigger does not provide is refused the same way, and one publish reports every refused action at once. The Failed to publish dialog shows one alert per action, titled with the channel, for example Email notification has invalid settings, summarized as 2 problems in the message and subject, and listing each problem. On the canvas, the refused action's card carries a red icon; open the action to see the same alert at the top of its settings panel. The mark is cleared by a Test Notification that gets past the check, whatever the channel then answers, and at the start of the next publish attempt. The refusal messages themselves are listed under Validation.

While Executions Run

While a Flow has executions in progress, its canvas becomes read-only and a banner explains that the Flow cannot be managed until they finish. Abort the running executions or wait for them to complete before editing. See Flow Executions.

See Also