Workflow

EEPer cluster

Visual designer for automation against Proxmox VE, built on Elsa Workflows. A reusable workflow is made of activities, each one a step such as a snapshot, a backup, a migration, a power action or a notification.

Features

Drag-and-drop Designer

Build workflows visually in Elsa Studio, embedded in cv4pve-admin: no external tool.

PVE Activities

Pre-built activities for guests (power, backup, snapshot, migrate, clone, resize), nodes (shutdown/reboot, inventory, RRD), storages (inventory, content, RRD), HA (manage state) and replications.

Admin Activities

Notify sends a message through the configured Notifier channels. Filter Collection filters the output of an inventory activity with an expression.

C# and JavaScript

Inline expressions in C# or JavaScript anywhere a value is accepted: branching, filtering, formatting.

History & Audit

Every workflow run is recorded with status, inputs and timing: inspect it from the History tab.

Multi-tenant

Workflows are isolated per cluster (tenant): a workflow designed in one cluster is not listed in another.

Why

Why a workflow engine when scripts and cron already work?

No scripts to maintain

Drag-and-drop, no Bash, no PowerShell, no SDK. Tasks that used to live in a wiki page become a workflow.

Branching and error paths

Conditions, loops, retries, error handling, without writing a state machine. The designer makes the control flow obvious.

Cluster-aware activities

Activities know your nodes, VMs, storages and HA groups: the pickers are filled from the live cluster, with no IDs to copy and paste.

Auditable runs

Every run is recorded with inputs, outputs and timing: answer "when did this happen and what did it do?" without digging through logs.

Sections

• Overview: short description of the module
• Workflows: the list of workflow definitions of the current cluster. Open a definition to edit it in the designer. When you run a workflow from the designer, the page switches to the view of that run
• History: the list of workflow runs (instances). Open a run to see its status and the detail of each step. From a run you can open its definition in the designer

The open definition or run is part of the page address: the browser Back button returns to the previous view, the page link in the module menu returns to the list, and the address can be bookmarked or shared with users who have the same permissions.

Workflows belong to the cluster selected in the cluster picker. Definitions and runs of one cluster are not listed in another. The activities of a workflow always act on the cluster the workflow was created in.

Requirements

• Configure the Urls setting of the application. The embedded designer calls the workflow engine of the same application at the first address listed there, under /api/elsa. Without Urls the application does not start.
• Expressions can be written in C# or JavaScript.
• The Proxmox VE user or API token of the cluster needs the privileges for the operations the workflows run. See Proxmox VE Permissions.

Available Activities

The module adds 26 activities to the designer toolbox, next to the standard ones of Elsa Workflows. They are organised under Proxmox VE and Admin. The full list, with inputs and outputs, is in Activities.

Permissions

The module defines these application permissions. All of them are included in the module administrator role.

Permission	Description
Workflow	Open the module and its Overview page
Workflows, History	Open the page with that name (one permission per page)
Workflow: Read, Create, Edit, Delete, Export	Workflow definitions
Workflow: Execute Workflow	Run a workflow
Workflow: Publish and retract	Publish a workflow, or retract a published one
History: Read, Export	Workflow runs
History: Delete	Delete workflow runs
History: Cancel	Cancel a workflow run that has not finished

Permissions are given per cluster. The designer shows only the actions the user holds on the cluster, and the workflow engine refuses the others even when they are requested directly. The pickers of the activities list only the nodes, guests and storages the user can read.

Editing a workflow is an administrator permission

The C# expressions of a workflow run as .NET code inside the cv4pve-admin process, outside the permission checks of the activities. Who can create or edit a workflow can read the configuration and the data of the application, the database connection string and the Proxmox VE credentials of every cluster included. Give Workflow: Create and Workflow: Edit only to users you would make administrators.

Who a workflow acts as

A workflow acts with the permissions of a user, never with more:

• Started from the designer: it acts as the user who started it. A run that waits (for example on a Delay) and resumes later still acts as that user.
• Started by a trigger such as Cron or Timer: it acts as the user who last published the workflow. If that user no longer exists or can no longer sign in, the run stops with an error: publish the workflow again with a valid user.

Each activity checks the permissions of that user on the guest, node or storage it acts on. An activity without permission stops the run with Permission denied, and the audit log records the operation under that user.

Persistence: Workflow definitions and runtime state are stored in the workflow_elsa Postgres schema, separate from the cv4pve-admin schema.

Proxmox VE privileges: the base (PVEAuditor), plus the privilege of each activity used. It is written in the block of each activity: see the list.

The inventory activities need the base only.

The base and the rules common to all modules are in Proxmox VE Permissions.