===== Workflows =====

**Workflows** allow you to automate actions on your devices based on conditions, measurements, or events.

A **workflow** is a graphical scenario composed of connected blocks.

{{ .:pasted:20260603-164217.png }}

Workflows can be configured:

  * Directly on a device
  * Within a template so they can be applied to multiple devices

They can be used to:

  * Automatically execute commands
  * Analyze metrics reported by drivers
  * Introduce logical conditions
  * Add delays and timing controls
  * Send email notifications
  * Automate maintenance or operational tasks

Workflows can be executed manually or triggered by a task (scheduled or on demand).

{{ .:pasted:20260609-104200.png?1200 }}

==== How Workflows Work ====

A workflow executes as a sequence of steps.

Each block receives data, processes it, and passes the result to the next block.

Depending on the results, the workflow can:

  * Continue execution
  * Follow a different path
  * Execute a command
  * Send a notification
  * Stop execution

==== Available Blocks ====

=== Retrieve a Measurement ===

This block retrieves the value of a metric reported by a driver.

Examples:

  * People presence
  * Audio volume
  * Temperature
  * Power status

The retrieved value can then be used by the next block.

=== Compare a Measurement ===

This block evaluates a measurement that was previously retrieved.

For example, it can verify whether:

  * A value is equal to another value
  * A value is greater than or less than a threshold
  * A boolean value is true or false

Depending on the result, the workflow can follow different paths.

=== Send a Command ===

This block executes a command available in one of the device drivers.

Examples:

  * Reboot a device
  * Put a display into standby mode
  * Change the volume
  * Switch video source

The available commands depend on the selected driver.

=== Wait for a Measurement ===

This block waits for a new value to be reported by a metric.

It is useful when the workflow must wait for a change in the device state before continuing.

==== Generic Blocks ====

=== Start ===

Entry point of the workflow.

Every workflow must start with this block.

=== Wait ===

Pauses workflow execution for a specified period of time.

Examples:

  * Wait 30 seconds before executing another action
  * Wait 10 minutes before performing a verification

=== Debug ===

Displays the data received or generated by the various workflow blocks.

This block is particularly useful when designing and troubleshooting workflows.

It can display:

  * Retrieved metrics
  * Comparison results
  * Data exchanged between blocks

==== Error Handler ====

The **Error Handler** block monitors errors returned by the different blocks within a workflow.

When a block generates an error in its payload (command execution failure, unreachable device, invalid data, communication error, etc.), the Error Handler detects the error and immediately stops the workflow execution.

This block is particularly useful for:

  * Preventing actions from being executed when prerequisites are not met
  * Stopping a workflow when a critical error occurs
  * Securing automated processes
  * Simplifying workflow troubleshooting and debugging

==== Notification ====

=== Send an Email ===

This block sends an email from the workflow.

You can:

  * Send messages to one or more recipients
  * Define a custom subject
  * Customize the email content

This feature is particularly useful for automatically informing operations teams.

=== Example: Reboot a Device When the Room Is Empty ===

In the example below, the goal is to automatically reboot a Cisco device when no presence is detected in the room.

{{ .:pasted:20260603-164240.png }}

The workflow operates as follows:

  - The workflow starts.
  - A measurement is retrieved from the Cisco driver.
  - The **People Presence** metric is analyzed.
  - If the returned value is **No**, it means that no presence has been detected in the room.
  - The workflow sends the **Reboot** command to the device.
  - An email notification is sent to inform users that an automatic reboot has been performed.

If the returned value indicates that someone is present in the room, no action is executed and the reboot does not occur.

This type of workflow makes it possible to automate many operational tasks while reducing manual intervention.

==== Tasks and Scheduling ====

Like presets, workflows can be executed:

  * Manually from the interface
  * Automatically through one or more scheduled tasks

Associating a workflow with a task allows it to be executed automatically at specific times.

This feature is particularly useful for:

  * Running recurring actions
  * Automating maintenance operations
  * Triggering scenarios at fixed times
  * Executing workflows across multiple devices simultaneously

To make a workflow executable by a task, simply associate it with one or more tasks during its configuration.

{{ .:pasted:20260603-164316.png?600 }}

=== Creating a Task ===

To create a task:

  - Go to **Configuration → Tasks**
  - Click the **➕ Add** button

You can then configure:

  * The task type (**Workflow**)
  * The task name
  * The execution days
  * The execution time

{{ .:pasted:20260603-164421.png?600 }}

A single task can trigger:

  * Multiple workflows
  * Across multiple devices

This makes it possible to centrally schedule identical actions on a large scale.

=== Time Zone Management ===

When executing a task, Zebrix Control automatically uses the time zone configured on the site associated with the device.

It is also possible to use Coordinated Universal Time (**UTC**).

== Example ==

A task named **Nightly Reboot** is scheduled:

  * Every Sunday
  * At 03:00 AM

This task is associated with several workflows across different devices.

At the scheduled time, Zebrix Control automatically executes all associated workflows without any manual intervention.