Automation Studio

The visual editor for automation playbooks. A playbook starts with one trigger event, optionally narrowed by filters, and follows one path through actions and Switch and Approve controls. Actions branch through Success or Error; a Switch chooses a named output by comparing variables; an Approve control waits for a human decision. The Studio opens when you create or edit a playbook from Automate → Playbooks.

flowchart LR
  trigger["Trigger event<br/>one per playbook · filters + cooldown"]
  a1["Action · Run Agent"]
  a2["Action · Email"]
  a3["Action · Webhook"]
  trigger -- "always" --> a1
  a1 -- "Success" --> a2
  a1 -- "Error" --> a3
  classDef triggerCls fill:#fff8e1,stroke:#fb8c00,color:#1e293b
  classDef actionCls fill:#eef5ff,stroke:#90caf9,color:#1e293b
  class trigger triggerCls
  class a1,a2,a3 actionCls

Execution is a single path: the trigger connects to at most one first step, and each output connects to at most one next step. An action offers Success and Error; a Switch offers one output per route, plus Fallback and Error; an Approve control offers Approved, Denied, and Expired. Alternative branches may reconnect to the same later step, which runs once on the selected path. Cycles and output fan-out are rejected; steps never run in parallel.

The page has three areas:

Header — enabled toggle, playbook name, Save button.
Palette (left) — the catalog you can drop onto the canvas, in three tabs (Events / Actions / Control).
Canvas (center) — the visual graph of the trigger, actions, and controls, with an Editor panel on the right for the selected node or connection.

The palette has a fixed width. Drag the divider between the diagram and Editor to resize the Editor; focus the divider and use the arrow keys for keyboard resizing. The Editor keeps a minimum width, and your chosen width is remembered in this browser. Collapse and expand a panel using its header button. Inputs are on the left of each step and outputs are on the right.

Select an event, action, or control and enter a Label in the Editor to give it a name that describes its purpose. Clear the field to restore its default name. Labels appear on the diagram and in step selectors; changing a label does not change connections or execution. Run history keeps the labels recorded when that run started.

What you can do

Pick the trigger event, configure its filters, and set a cooldown to throttle repeat firings.
Drop actions on the canvas and wire their Success and Error outputs to the next steps.
Configure each action’s parameters and retry behavior in the Editor panel.
Add a Switch with ordered routes and connect its named outputs.
Add an Approve control to pause for a human decision, with separate approved, denied, and expired branches.
Name the playbook, enable or disable it, and save.

Authoring in the Studio requires the Automation feature in your license. Without it, the Studio opens read-only and the Save button is locked.

Common tasks

Pick the trigger event

In the Palette, open the Events tab.
Click (or drag onto the canvas) the event you want the playbook to react to — for example Resource Health Changed, Resource Session Stopped, Resource Config Changed, or Compliance Violation. See Trigger events for the full catalog.
A playbook can only have one trigger. Other event tiles in the palette are dimmed while a trigger is set — change the trigger by removing the existing one from the canvas first.

Add trigger filters

Filters reduce noise by letting a playbook fire only when the triggering event matches certain conditions (for example, only critical severities, only Cisco resources).

Click the trigger node on the canvas.
In the Editor panel on the right, find the Filters card and click Edit. The Edit Filters modal opens.
Under Available Filters, click + on a field exposed by this event (the list is scoped to what the event emits), then pick an operator (equals, not equals, contains, greater than, …) and a value.
Repeat for additional filters — all conditions must match (AND logic) — then click Apply.

The Filters card summarizes the configured conditions; with none, the playbook matches every event of this type. (The On Schedule (Cron) trigger has no filters — the schedule itself is the filter.)

Throttle with a cooldown

The trigger’s Event card in the Editor panel has a Cooldown (seconds) field. While the cooldown is running, a repeat firing of the trigger still creates a run, but the run is recorded as Suppressed and no actions execute — see Runs. The accepted value is any non-negative whole number; zero disables the cooldown. Cron schedules have one-minute resolution, so a cooldown below 60 seconds normally adds no throttling.

Add actions

In the Palette, open the Actions tab.
Click or drag the action to place it on the canvas.
Wire it in by dragging a connection from an output port of the previous node to the action’s input port. The trigger has a single output port; every action has two — Success and Error — and the port you drag from decides when the connection fires. Click a connection to see its condition in the Editor panel, or to remove it.
Click the action node and fill its parameters in the Editor panel. Parameters vary by action — see Actions for the full catalog. Each action also has Max retry and Retry interval (s) fields for automatic retries on failure.

Set up bindings

Bindings give names to the data that a step needs. Actions, Switch, and Approve use the same Bindings section in the Editor.

Select the action or control, then click Bindings → Edit.
In Available Sources, find the event field, incoming data, or earlier step result you need. Click + to add it to Active Bindings.
Enter a Variable name, such as analysis or resource_name. Names start with a letter or underscore and contain only letters, digits, and underscores.
Repeat for other values, then click Apply.

Templates use those names, for example {{ analysis }} in an Email body or Approve message. Switch conditions select them from the Variable input. Bindings belong to the selected step; add a binding to each step that needs it.

Source labels identify the action and its custom label when one is set, such as Run Agent (Analyze change). The picker offers earlier steps that execute on every path leading to the selected step. A sibling branch or later step cannot supply a binding. Editing connections or removing a source step can invalidate bindings; resolve the displayed errors before saving.

Incoming data comes from the most recent action on the path actually followed. Switch and Approve forward that data unchanged. Where branches reconnect, the offered incoming fields have compatible types across the possible sources. Bind to a specific earlier step when you need that step’s result regardless of intervening actions.

For a dynamic field not listed in the picker, expand Advanced source path inside Available Sources, choose its source, enter its path, and add the binding. Paths select fields and numeric array indexes; they do not evaluate expressions. Confirm the field’s actual shape in run replay, since dynamic fields are checked when the step executes.

Route with a Switch

Add Switch from Control, define its bindings, then create named routes that compare those variables. Each route uses All conditions (AND) or Any condition (OR). Routes are checked in order and only the first match runs. Drag a route’s header handle to reorder it, whether expanded or collapsed.

Connect the named outputs to their next steps. Fallback handles data that matches no route; Error handles a comparison that cannot be evaluated. See Switch control for setup, comparison types, optional values, lists, and examples.

Wait for approval

Add Approve from Control. Configure its approver roles, expiration, title and message templates, and optional email. Bind event fields or earlier results into the templates to explain the decision to the reviewer.

The run pauses until one eligible user decides or the request expires. Connect Approved, Denied, and Expired to their next steps. Reviewers respond from the top-navigation message icon without needing access to the Studio. See Approve control for the complete setup and decision workflow.

Chain actions

Most actions emit an output that the next action can consume. For example, a Run Agent action’s reply can be inserted into the body of an Email action wired to its success port.

Execution follows one path through the graph: after each action, the run takes its connection for that outcome; after a Switch, it takes the selected route, Fallback, or Error connection; after an Approve control, it takes Approved, Denied, or Expired. Unvisited steps are marked Skipped when the run finishes. Branches may reconnect to one shared continuation; this does not synchronize or execute both branches.

An unconnected action output ends with that action’s outcome. An unconnected Switch route or Fallback preserves the incoming run outcome; its Error output ends Failed. An unconnected Approve output ends successfully for Approved and Failed for Denied or Expired. A successful later action can handle a failure and finish the run successfully; a Switch alone cannot clear a failure.

Enable and save

Rename the playbook in the Playbook name field at the top.
Flip the enabled toggle at the top left — disabled playbooks do not receive events and are safe parking spots for work-in-progress.
Click Save to persist changes.

The Save button is enabled once the playbook has a name and a trigger event. Every step must be reachable from the trigger. Remaining problems, including invalid rules, broken references, or unreachable steps, appear inline where applicable and in the Cannot save playbook dialog. An unconnected output that ends the run is allowed.

Replay a past run

To inspect how a past execution went, use the Runs tab and click a run to open it in replay mode. See Runs.

Trigger events

A playbook fires on exactly one of these events. The palette’s Events tab lists them all; each event exposes its own set of fields for filters and for binding into action templates.

Resource lifecycle

Event	Fires when
Resource Created	A resource is added to inventory.
Resource Updated	A resource’s fields change.
Resource Deleted	A resource is removed from inventory.

Status & health

Event	Fires when
Resource Reachability Changed	A resource’s reachability status changes (verified, unreachable, auth failed, …).
Resource Health Changed	A resource’s health status changes (healthy, degraded, critical, unknown).
Snapshot Failed	A resource snapshot task fails — connectivity loss, auth failure, or timeout.

Configuration

Event	Fires when
Resource Config Changed	A resource’s captured configuration changes between snapshots.
Resource Config Pushed	A configuration-stack push reaches a terminal state (ok or fail).

Sessions

Event	Fires when
Resource Session Started	An interactive session opens on a resource.
Resource Session Stopped	An interactive session ends.
Resource Session Recorded	A session’s review material (replay / transcript) becomes available.
Session Policy Notify	A Session Policy rule with Notify on matches (allow or deny).

Compliance

Event	Fires when
Compliance Violation	A Fact Policy rule transitions to fail on a resource.
Compliance Resolved	A Fact Policy rule transitions from fail or error to pass on a resource.

Fleet & security

Event	Fires when
Worker Status Changed	A worker goes online or offline.
Sensor Status Changed	A sensor’s status changes (online / offline / error). Requires the IDS feature.
Sensor Alert Matched	An intrusion-detection alert matches an IDS Policy rule with Notify on. Requires the IDS feature.
Collector Log Matched	A device log matches a Syslog Policy rule with Notify on. Requires the Collector feature.

Schedule

Event	Fires when
On Schedule (Cron)	A cron schedule you set matches. There is no resource context — the schedule itself is the trigger, so pair it with an action that names its own targets (for example Dispatch Resource Action or Generate Report). Selecting this trigger adds Schedule fields (Minute / Hour / Day / Month / Weekday) and one-click presets to the Editor panel.

Actions

The palette’s Actions tab lists these actions; wire them after the trigger, a control, or another action, and fill their parameters in the Editor panel. A playbook may also end at a control output.

Action	What it does	Key parameters
Run Agent	Runs one AI agent against the event’s context.	The Background agent to invoke (only background-capable agents are offered), and bindings that map event fields into the agent’s context.
Email	Sends one rendered email.	To / Cc / Bcc, subject template, body template.
Webhook	Sends one HTTP request to an external endpoint.	URL, method (POST / PUT / PATCH), headers, body template (with ready-made templates to start from), timeout, TLS verification, and optional authentication.
Run Tool	Runs a network diagnostic from one or more workers.	The tool, its parameters, and up to five optional workers. With no worker selected, the first available worker in root-first location order is used.
Dispatch Resource Action	Runs snapshot, info, health, or config collection on one or more resources.	The action to run and the target resources (a fixed list or bound from the event).
Push Config Stack	Renders a configuration stack and pushes it to one or more resources.	The stack and the target resources.
Generate Report	Runs a report template and emits a shareable link (plus an optional AI executive summary) for downstream actions to use.	The report template.

Most actions produce an output that the next action can consume — for example, a Generate Report action’s link and summary can be inserted into an Email body, or a Run Agent reply into a Webhook payload.

Run Tool uses the same diagnostic definitions and input validation as Monitor → Tools. Worker selection is global rather than limited by resource location scope. Most diagnostics observe network behaviour, but HTTP methods such as POST, PUT, PATCH, and DELETE can change their target.

Node colors on the canvas

Node	Color
Trigger (event)	amber
Action	light blue
Control (Switch or Approve)	light purple

When you replay a past run (see Runs), borders and status text show running/retrying, waiting for approval, success, failure, or skipped. Select a Switch to inspect the selected output and condition evidence. Validation problems appear in the Cannot save playbook dialog; Switch rule problems also appear inline in its editor.

Permissions

Open the Studio: app.automation.read (read-only without more).
Edit and save: app.automation.write, plus the Automation license feature.