Workflows

The Operate Console

An operations view for running processes — every instance by status, failures surfaced as retryable incidents, and batch cancel/retry across many runs at once. When a step fails, it becomes an incident you resolve or retry in one click, and the process picks up where it left off.

Running a process at scale means watching many instances and dealing with the ones that go wrong. Operate is that view: it lists every process instance by status, turns failures into incidents you can act on, and lets you cancel or retry across many runs at once. It's the equivalent of Camunda Operate — an operations console for people who run automation, not author it.

This is part of BPMN Process Orchestration.

The Operate console — an open-incidents banner with Retry/Resolve, and the instance list with status, incident counts, and batch-select checkboxes

Instances

Workflows → Operate shows process instances, filterable by state:

  • Active — running, waiting for approval, paused, or pending.
  • Incidents — instances with at least one open incident.
  • Failed / Completed — terminal outcomes.
  • All — everything.

Each row shows the run name, its workflow, a status pill, a BPMN tag for process-mode runs, and an incident badge counting open incidents on that run. A checkbox on every row drives batch operations.

Incidents

When a step (or a decision, or a gateway with no matching route) fails in a process-mode run, Versus opens an incident instead of just marking the run failed and moving on. The incident captures what failed, where (the activity), and why (the error message) — and it's actionable:

  • Retry — re-queues the failed element on the run's token frontier and resumes the process. If the underlying problem is fixed (a device came back, a transient error cleared), the step runs again and the process continues from exactly where it stopped. If it fails again, a fresh incident opens.
  • Resolve — closes the incident without retrying, for when the failure was expected or handled out of band.

The open-incidents banner sits at the top of Operate so nothing gets missed, and each incident links back to its run and activity.

Batch operations

Select any number of instances with the row checkboxes and act on all of them at once:

  • Retry — retries every open incident across the selected runs.
  • Cancel — cancels the selected runs (finished runs are left alone).

Batch operations are how you clear a backlog after an outage — retry the fifty runs that stalled on a device that's now healthy, or cancel a batch that's no longer needed, in a single action.

Why incidents beat a failed status

A plain "failed" tells you that something broke; an incident tells you what, where, and how to recover — and lets you recover in place, without re-running the whole process from the top. A three-datacenter upgrade that failed verifying DC-C doesn't restart DC-A and DC-B; you retry the one step, and the process finishes. That is the difference between a script and a recoverable process.

For duration and bottleneck analytics across all those instances, see Optimize — Process Analytics.