Approvals Explained

Nodlyn uses three different approval mechanisms. They answer different questions. This page explains who can approve, where to look, and what security to expect.

Simple rule (v1)

Where the workflow runs	Where to approve	What security means
Studio (test, dry run, execute in UI)	Full-screen safety banner + Activity → Jobs → Approvals	Login + roles — real identity
Exported runtime agent (headless server)	Built-in dashboard on port 9090	Safety interlock — run pauses until someone confirms; not the same as Studio login

There is no email, Teams, or webhook setup for approvals in v1. Open the right UI when a run needs a decision.

1. Safety gates (Dangerous / Armed nodes)

When a workflow step is classified Dangerous (e.g. shell command, Modbus write), execution pauses until a human confirms. Armed Required adds a second step (two-person rule).

Studio — who can approve?

Action	Minimum role
Approve	Operator, Supervisor, or Admin
Arm	Supervisor or Admin

No named assignee — any user with the right role who is signed in can act. The full-screen banner appears when a run suspends.

Runtime agent — what approval means here

On an exported agent, safety approval is a pause + confirm, not role-based access control:

The workflow stops automatically at the Dangerous step.
An operator opens the dashboard and clicks Approve / Arm.
They enter an operator name (stored in the audit log — accountability, not login).
Arm requires confirmation text and a different name than Approve (two-person procedure).

Who can reach the dashboard?

Windows agent — dashboard listens on 127.0.0.1 by default (local machine only).
Linux/macOS agent — listens on all interfaces; restrict port 9090 with firewall/VLAN if needed.
With Operator approval support enabled at export, remote Approve/Arm from LAN requires DashboardActionToken (?accessToken= once, or localhost).

Do not expect the same identity guarantees as Studio. Treat the agent network as a trusted perimeter (factory LAN, VPN, physical access to the server).

2. Business approvals (`approval.requestApproval`)

For purchase orders, access requests, document sign-off, etc. Set the designated approver on the node:

approver: [email protected]

Studio — who can decide?

Designated approver — email, user id, or display name must match (case-insensitive).
Supervisor or Admin — may decide any pending request.
Decide in Activity → Jobs → Approvals (signed in).

Runtime agent — separate inbox

Business approvals created on the agent are stored in the agent’s local database. They appear on http://<agent>:9090/approvals — not in Studio Jobs → Approvals.

The approver enters their email or name; it must match the approver field on the request. This is identity by declaration, not Studio login.

For teams that need strong identity on business approvals, use workflows that run in Studio or poll approval.checkApproval after a human decides in Studio.

3. Workflow lifecycle (design-time)

Before a workflow goes Active: Draft → Validated → Approved → Active. Only Admin can lifecycle-approve. Unrelated to runtime suspensions.

User roles (Studio)

Role	Typical use
Viewer	Read-only
Operator	Run workflows; safety Approve; business when designated
Supervisor	Operator + Arm + any business approval
Admin	Full control + lifecycle + users

Export runtime

In Export Runtime, optional checkbox Operator approval support:

Auto-checked when the workflow has Dangerous or business-approval nodes.
When enabled: pre-fills DashboardActionToken for remote Approve/Arm from LAN.
When disabled: dashboard still exists; use localhost or rely on network perimeter.

Set Runtime:ControlPlaneUrl in Studio appsettings.json to your LAN IP so agents can heartbeat (e.g. http://192.168.1.10:5010).

Approval vs event ingress

External HTTP/MQTT consumers (/api/agent/event) are not blocked by approval suspend and cannot approve Dangerous nodes. See Runtime Event Ingress.