Running Workflows on Demand (with Parameters)

Last updated

Besides its own triggers, a workflow can be started by a person, a dashboard, a script, another workflow, a schedule or an alarm pipeline. All of these work whether or not the workflow is enabled, and all of them need the workflow to contain at least one trigger node — put a Manual trigger in workflows meant only for these.

Started from	Parameters?	Waits for the result?
Run now on the Workflows list, Run Now in the editor	No	No
Dashboard Button widget	Yes, typed or from tags	Optional
Run Workflow node	Yes	Yes
Script: `workflows.run(...)` / `workflows.trigger(...)`	Yes	run: yes; trigger: no
REST: `POST /api/workflows/:id/execute`	Yes	Optional
Schedules page	No	—
Alarm pipeline Run Workflow step	Alarm details	—

Run Now

Run Now starts the saved version with no parameters. On the list page nothing tells you when it finishes; in the editor, History opens after the run starts — reopen it after a moment to see the final status.

From a dashboard button

A Button widget with its action set to a workflow can:

run it, enable it or disable it (the Do What setting);
pass Parameters — each one a typed value or a tag read at the moment of the press;
with Show result after running (on by default), wait for the run to finish and show completed or the error message; with it off, the button only reports that the run started.

Example — an operator scrap button on an HMI: parameters line = 2, reason = Short shot, count = tag Press2/RejectCount. The workflow uses {{line}}, {{reason}} and {{count}}. See Button.

From another workflow or a script

Use the Run Workflow node (see Input / Output Nodes) or the workflows object in a script (see Scripts and Workflows).

From another system (REST)

Method	Path	Purpose
POST	/api/workflows/:id/execute	Start a run
GET	/api/workflows/:id/executions	Last runs (`?limit=`, default 50)
PUT	/api/workflows/:id/enable	Enable or disable (`{"enabled": true}`; no body toggles)
GET	/api/workflows	List workflows with last status

These endpoints take a user sign-in token (Authorization: Bearer <token> from POST /api/auth/login) — not an API token. Starting a run needs an Operator, Editor or Admin account (and a run grant if the workflow is restricted); enabling or disabling needs Editor or Admin. Body of the execute call:

json

{
  "params": { "line": 2, "reason": "Short shot", "count": 14 },
  "wait": true
}

params — each key becomes a variable, {{line}} and so on. It may also be a list of {"name": "count", "source": "tag", "deviceId": 3, "tagPath": "Press2/RejectCount"} entries, the format a button uses.
wait — true holds the request open until the run ends and returns {"executionId": 812, "status": "completed"} (or "failed" with "error"). Without it the call returns at once with {"status": "running"}.
A parameter cannot overwrite trigger or userId.

bash

curl -X POST http://scada.local/api/workflows/12/execute \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"params":{"line":2,"reason":"Short shot"},"wait":true}'

Running Workflows on Demand (with Parameters) ​

Run Now ​

From a dashboard button ​

From another workflow or a script ​

From another system (REST) ​

See also ​

Running Workflows on Demand (with Parameters)

Run Now

From a dashboard button

From another workflow or a script

From another system (REST)

See also