TaskEditor

A task is an automation rule. You build it visually: drag operations onto the canvas and wire them together. The client compiles the task as you go and tells you immediately what it finds.

The Workspace

When you open a task, you see three panes:

Operations catalog on the left — all the operations your server offers, grouped by extension.
Canvas in the middle — where your task graph lives.
Details panel on the right — shows what’s configured on the node you have selected.

Drag the splitters between panes to resize them. Your layout is remembered.

Adding an Operation

Find the operation you want in the catalog on the left and drag it onto the canvas. It becomes a new node at the drop point.

Each operation has its own reference page — look for the link in the node’s details panel on the right to learn what it does and what its inputs and outputs mean.

Connecting Operations

Operations have ports on their edges — inputs on the left, outputs on the right. Drag from an output port of one node to an input port of another to wire them together. A dashed line follows your cursor during the drag.

If a connection isn’t valid (incompatible types, or the input already has a source), the drop is ignored — the Editor checks every connection as you wire it.

Hover a port to see what it needs: a Gate Input (marked >) reads “Gate — when off, this step and everything after it is skipped”; an unconnected Mandatory input reads “Required input — not connected”; other inputs read “Connected” or “Optional input” depending on whether something is wired to them.

Moving and Selecting

Click a node to select it — its details show in the right panel.
Drag a node to move it. Multi-selected nodes move together.
Drag on empty canvas to draw a rubber-band selection.
Use Ctrl+A to select everything, Ctrl+Shift+A to clear the selection.

Nodes stay inside the canvas work area; you can’t drag them outside.

Configuring a Node

When a node is selected, the right-hand details panel shows its settings. Depending on what the operation needs, you may see:

Text inputs for names, labels, and free-form strings.
Numeric inputs for thresholds, counts, and similar values.
Toggles for yes / no options.
Dropdowns for choosing from a fixed list.
Pickers and references for pointing at other things in your system.
Calendar, time, duration, and cron builders for scheduling values.
Tables and lists for entries that repeat.
Read-only labels when the field is just informational.

Edits are committed when you leave the field. Everything you do goes on the undo stack — Ctrl+Z to undo, Ctrl+Shift+Z (or Ctrl+Y) to redo.

Moving Around

Mouse wheel — zoom in / out at the cursor.
Middle-mouse drag or Shift + left-drag — pan.
Right-click on empty canvas — context menu with cut, copy, paste, duplicate, selection and zoom actions.

Zoom buttons are in the toolbar:

Button	Shortcut	What it does
Zoom in	`Ctrl++`	Zooms in one step
Zoom out	`Ctrl+-`	Zooms out one step
Zoom to fit	`Ctrl+0`	Fits all nodes in the viewport
Reset zoom	`Ctrl+1`	Back to 1:1
Overview	`Ctrl+2`	Full zoom out
Frame selection	`Ctrl+Shift+F`	Fit the selected nodes

Your pan and zoom are remembered — the next time you open the task, the viewport is where you left it.

Copy, Paste, Duplicate

Standard clipboard actions work on the selected nodes:

Ctrl+C / Ctrl+X / Ctrl+V — copy / cut / paste.
Ctrl+D — duplicate in place.
Delete — remove selected nodes and their connections.

Pasted nodes land where your cursor is, or in the middle of the viewport if the cursor is outside the canvas.

Hover Highlighting

Hovering over a node highlights the chain of nodes connected to it — useful when tracing what triggers what in a busy graph.

Saving, Verifying and Deploying

The Editor’s toolbar carries three actions:

Save — stores the draft on the server. Save is available once the task’s own required fields — its Name — are filled; nothing inside the graph withholds it, however broken the graph is, so you can save a draft mid-edit and come back to it later.
Verify — asks the server for its verdict on the draft and shows it in the findings list. It produces nothing that is kept.
Deploy — publishes the draft, so the task can run. Deploy always verifies first — a draft carrying an error is not published.

The tasks list has its own toolbar for the published task: Add, Edit, Deploy, Run, Stop and Delete. The list also shows a Verified column with each task’s standing — Never, Passed, Warnings or Failed — marked (outdated) when the graph or the server’s validation rules have changed since that verdict.

Opening a task without editing it shows you the deployed graph. Compile diagnostics belong to the draft, so the Editor is where you read them.

Errors and Warnings

The Editor reports problems with the graph on two surfaces: a live layer that tracks every edit, and a Verify report that carries the server’s verdict.

The live layer

The live layer is instant and local — the Editor checks the graph and every node’s settings as you edit and marks what it finds, with no server round-trip:

A mark on the specific field or port row in the details panel that carries the finding — an error, a warning or an info mark.
A frame around each affected node — solid for an error, dashed for a warning. A node whose worst finding is information carries a small info badge instead.
A ring on a port a finding is about — a danger, a warning or an info ring.
The findings list below the canvas. Its Local tab holds what the Editor finds as you edit; click a row to locate and highlight the node — and the port or field — it refers to. Rows are ordered worst first, then by node.

Hover a node’s header or its badge to read what its findings say. A port’s tooltip shows the port’s own description, then its findings.

Where a node, a port or a field carries several findings, the worst one sets its mark: a node with an error and an information finding shows the error frame and no badge. The tab counts count errors and warnings; information findings are listed but not counted. A note is one of them — a finding that asks you to change nothing, such as a hint that an input might read data from an operation that continues after errors.

Advice

Some findings are advice: the node runs, but probably does not do what you meant. A Funnel with one input connected has nothing to choose between; a Counter with neither Up nor Down connected never counts; a Random whose Min equals its Max always draws the same number. Each operation states its own advice, and the Editor shows it as you edit, from the same check the server makes at Verify and Deploy. Connect the second input or change the setting and the advice clears at once.

Advice comes at one of two grades:

Warning — probably a mistake. A dashed frame on the node, a warning ring on the port, a warning mark on the field.
Information — has no effect as set. An info badge on the node, an info ring on the port, an info mark on the field.

Hovering shows the finding’s sentence, ending with the advice — for the Funnel, “Funnel picks between two or more inputs; connect at least two”. Each operation’s page names the advice it gives.

A field left at its type’s default carries no mark in the details panel from its own rule, whatever grade that rule states — an empty Template on a Report, say. That finding still shows on the node and in the findings list.

The Verify report

Press Verify to send the draft to the server; Deploy does the same before publishing. The result replaces whatever the findings list’s Remote tab held before, and switches you to it. The tab shows:

“Result received <time>” — when that result landed.
A note appended to that line when the graph has since been edited, so a result you’re reading may not match what’s on the canvas.
A row for each of the server’s validation findings, or a line saying the result found none.

Why Verify matters

The Editor checks your graph as you edit against the same rules the server judges by — the rules stated on each field and on each node as a whole — so anything the live layer flags, the server would flag too.

What the live layer can’t run is each operation’s own check: whether a cron expression has the right number of fields, whether an MQTT topic sits under a prefix you may use, whether an operation is one the server actually offers, whether you are inside your capability limits. Those need the server itself — its parsers, its catalog, your account’s limits — and only Verify or Deploy can make them.

Which means: trust the live layer when it reports a problem, but not its silence — a graph it says nothing about can still fail an operation’s own check. Press Verify when you want the server’s verdict, and watch for the Remote tab’s edited-since note to see whether that result still covers the graph on your canvas.