Using the workflow designer

In user language: for workspace admins and people who configure workflows. One article covering opening the canvas, dragging nodes and wires, how each node is set up, where workflow variables come from and go, and how to inspect them at run time.

Field-level implementation notes: docs/core-mechanisms/workflow.json-v1.md, docs/core-mechanisms/工作流.md (read when integrating; not UI copy).

Example definition: examples/workflows/iway-6-factory-audit/workflow.json.

Date: 2026-07-31

This article merges the former “Workflow nodes” and “Using the workflow designer”. The old link Workflow nodes still works; its content points at the matching sections here.

Contents

1. Get the big picture first
2. Where to open it, and which template
3. Three panes and how to work the canvas
4. Workflow variables: how they work, how to inspect them
5. Fields shared by every node
6. Node details (what each node reads and writes)
7. Getting started and business examples
8. Save, run, and publish (includes trial highlight, test instances)
9. FAQ
10. Implementation map

1. Get the big picture first

A Cadau workflow is more than a to-do list. From IWAY factory audit to simple expense / onboarding, the same visual workflow designer sits behind it: you drag nodes and wires on the canvas, save, then colleagues start an instance under Run (or HR auto-starts one when an onboarding case is closed). Work items go to the people who should handle them.

Human nodes (form, upload, approval, app work) appear in My work items; app work also creates a work ticket. Automatic nodes (load standards, confirm/return staffing request, score, rule branch, agent work, call a workflow) are run by the engine or a plugin; agent work shows queue/run status on the instance detail.

Each workflow has one start (select a node → “Set as start”). After edits, save the workflow design; that only affects instances started later.

Four layers:

Template → workflow definition (what the designer edits) → instance (one run) → work item / work ticket (who does this step)

2. Where to open it, and which template

1. Open Workflows in the top bar
2. New workflow or My workflows → Open an existing one
3. Click Workflow settings → Workflow design

Only workflows created from a generic template have this designer, for example:

Classic “on-site compliance inspection” still uses the old engine and has no canvas; new workflows should use one of the templates above.

3. Three panes and how to work the canvas

┌──────────┬─────────────────────────────┬──────────────┐
│  Node    │         Canvas               │  Node        │
│  library │  Drag / wire / select        │  properties  │
│  Click   │  Delete removes a node       │  Form,       │
│  to add  │  (start cannot be deleted)   │  handler,    │
│          │                              │  branches,   │
│          │                              │  variables   │
└──────────┴─────────────────────────────┴──────────────┘

When done, click Save workflow design at the top right. Save writes the definition; only instances started after that follow the new design. In-flight instances are unchanged.

4. Workflow variables: how they work, how to inspect them

4.1 In one sentence

Each workflow instance has a variable table (implementation: variables on the instance payload). Values written by earlier steps can be read later: same-name form fields prefill, handler “form variable”, {{variable name}} in an agent task note, app-work results written back — all go through this table.

Inspection-style workflows also have side-channel data (checklist, score summary) on other payload fields; those may not enter variables — see each node’s “writes” section.

4.2 At design time: how to know which variables will exist

The product currently has no separate “variable dictionary” page. Configure from this table:

When debugging, walk the canvas left to right and list “this workflow’s variables”: start inject ∪ each form key ∪ each result variable ∪ approval fixed keys.

4.3 At run time: how to see what a step had

“Variables the node receives” = every key already in the variable table when the flow reaches that step (start inject + everything previous steps wrote). “Variables the node writes” = keys added or overwritten in the table after the step finishes (see each node below).

4.4 Variables injected when HR closes a case

Under HR → Settings → Hire / Leave / Transfer, if you check “auto-start on close” and pick a workflow, closing that lifecycle case starts the workflow with the following variables (even if step 1 is app work or agent work, they are already on the instance).

How to reference them when configuring

• Handler type Form variable → fill handler_user_id or warehouse_user_id (a handler must be set in Settings).
• Agent work · task note example: Handle remaining onboarding for {{display_name}} (employee number {{emp_no}}).
• Keys written back when app work completes (e.g. mindlink_user_id) are unrelated to the table above; they come from the node’s result variable whitelist.

Product help (including the variable table): help/product-features/platform-hr.md (auto-start workflow after closing hire/leave/transfer). Implementation truth: written when the HR plugin closes a lifecycle case and starts the workflow (plugins/hr). To inspect run results, still use §4.3.

5. Fields shared by every node

Select any node; the right pane usually shows first:

5.1 Handler (human nodes only)

The form-variable name must match a key in the variable table. Example: field key=approver_user_id, handler type “Form variable”, fill approver_user_id.

Several named people (fixed list): approval nodes only. At design time pick people from the roster or workspace members (at least two; the same person counts once). On arrival each person gets a to-do at the same time.

If the group changes (whoever is on finance duty), keep using Business duty (claimable): that is one shared to-do, not a parallel send.

Workspace identity: identity at invite time — owner / admin / member. Owners can also claim admin work items; admins can also claim member work items.

Business duty: create and bind members under Workspace collaboration → Members and invites → Business duties. After the workflow picks “Business duty”, duty members can claim under My work items. The same duties can also authorize assistant capability packs.

Department headcount seat: maintain seats in the HR plugin Department headcount. The designer has three ways to pick:

1. Pick a seat directly: pin one seat (e.g. “Finance · expense review”).
2. Pick a department, then a seat: at design time, choose from that department’s seat list.
3. Resolve from the starter’s department: pick only a job template; department comes from start variables (default department_ids). Fits “the same job in every department”.

Resolve order: short-term seat proxy → primary incumbent → (after account mapping) person-level handling proxy.

Agent decides: pick a workspace agent and a decision note (may include {{variables}}). Rule detail lives in that agent’s knowledge documents or skills. On arrival the engine asks the agent synchronously; it picks a handler among business duties / department seats / users / workspace identities; the reason is written to assignee_agent_reason. You can configure a fallback business duty on failure. For ordinary “manager → finance”, prefer seats + duties + amount branches; use agent decide only when the rule is hard to draw.

5.1.1 Leave / temporary substitute

5.2 Wire conditions (outgoing)

Default is Next. When you drag multiple wires from Approval, Rule branch, Agent work (if branches are configured), set a condition on each outgoing wire on the right:

6. Node details (what each node reads and writes)

“Receives” below always means the variable table already present when this step is reached (plus inspection side-channel data). Keys not listed are still readable later if an earlier step wrote them.

6.1 Fill a form

Meaning: collect business information into this instance’s variables.

How to set it up

1. Click Fill a form on the left to add it, or change an existing node’s type.
2. Change the title (e.g. “Leave request”).
3. Step mode (right): default Ordinary form; if this step is compliance CAP remediation, pick CAP remediation (explain failed items) — the handle desk lists failed items and supports “fill from findings”; no custom fields needed.
4. For an ordinary form, add fields in Form fields:

- Display name: the label the user sees (on blur, a field key is generated, plus inferred type / required; line-item columns also infer aggregation, still editable) - Field key: name written into variables (English snake_case, good as a column name) - Type: text, number, multiline, date, datetime, options, attachment, line items, … - Required, width (full / half / third…), auto-fill (current user, department, today, now; not for attachments)

1. If type is options, add each item’s display name (what the handler sees) and saved value (written to the variable; may match the display name) under Choices.
2. For materials, type attachment: the handler can upload one or more files (photos, PDFs, office docs, …).
3. For multi-row detail, click Add line-item table, then configure columns (numeric columns can have sum/count, …).
4. Configure the handler (start forms are often “Starter”).
5. Use Test form to try filling (not persisted; attachments do upload so you can preview).

Tip: if a later “finance pay” form uses the same field keys, already-filled values are brought in; you only add pay-specific fields.

| | Content | |--|------| | Receives | All variables already present at start (including hire inject); same-name fields prefill when handling | | Writes | Each field key → submitted value; line-item table key → array of row objects; attachment key → list of attachment ids |

Example A: leave request (start)

Wires: Fill leave → Approval → (pass) End / (fail) End (failed)

Example B: expense line items — see §7.4.

6.2 Upload evidence

Meaning: for already-loaded checklist items, the handler uploads photos or files.

How to set it up

1. The workflow definition must bind a compliance questionnaire in Basic settings (items are maintained in Compliance).
2. Suggested canvas order: Load inspection standards → Upload evidence → Auto score.
3. Check or uncheck Must upload every item (whether missing items can continue).
4. Configure the handler.
5. When handling, each item can take several on-site photos; thumbnails appear after upload. Analyze produces comments, a score, and a conclusion against that item’s scoring notes and photo standard. In one item per page, paging or jumping auto-saves the current item (still there after refresh). After every item is done, tap Submit evidence and comments at the bottom to go on. Submitting with blanks first shows a confirm.

| | Content | |--|------| | Receives | Variable table (factory name, audit type, …); checklist written by Load inspection standards (payload side, for per-item upload) | | Writes | Usually no business keys into variables; evidence hangs on the instance/items for later Auto score |

Example: IWAY factory audit: start info form → load standards → upload evidence → auto score → rule branch.

6.3 Approval

Meaning: one person (or a claimable role) passes / rejects; you can also name several people for countersign / any-one sign. Do not draw a “signature field” on a form as a substitute for an approval node.

How to set it up

1. Add Approval, title e.g. “Department lead approval”.
2. Handler: for one person, often “Form variable” → approver_user_id, or a named employee. For several people at once: Several named people (fixed list), pick Countersign or Any-one sign, then Edit in dialog… to write the list. The canvas defaults to one node per person (everyone inside the same countersign box so the flowchart is easier to read; they still act at once). You can switch to Single node to show one box.
3. Drag two wires: outgoing Pass / Fail (red line).
4. On the fail end, check Mark as “failed” end.

| | Content | |--|------| | Receives | Variable table (resolve handler); document contents prefer approval_doc on the instance (injected when the business starts the run, same idea as compliance check items). If there is no snapshot, show earlier form fields | | Writes | approval_decision (overall pass/reject), approval_note (comment), approval_votes (one row per person; visible while countersign is in progress) |

Approvers must see everything they need on this step and must not be sent back to HR or another app. Workflows started from a business document (staffing request, hire/leave/transfer, and similar) must include approval_doc. On-site compliance shows check items on the upload-evidence step — same principle.

Example: simple one-step approval

flowchart LR
  A[Fill request] --> B[Approval]
  B -->|pass| C[End]
  B -->|fail| D[End · failed]

The Simple approval template gives a similar canvas.

Example: countersign (one node per person)

Handler → Several named people → Countersign, then Edit in dialog… to name A, B, C. The canvas draws the three people inside one countersign box; three to-dos go out at once; all must pass before the Pass wire; one reject takes the Fail wire and cancels the rest. To show a single box, switch How to draw it to Single node; the list still lives in the dialog.

flowchart LR
  A[Fill request] --> B[Countersign A B C]
  B -->|pass| C[End]
  B -->|fail| D[End · failed]

Example: any-one sign

The same list with Any-one sign: the first pass or reject ends the step; the others’ to-dos are cancelled. The canvas can still be one node per person or a single node.

Staffing-request approval has two wirings — see §6.3.1: create hiring requisitions immediately on pass, or leave the document awaiting execute for the submitter.

6.3.1 Staffing request: two wirings after approval

Meaning: approval only decides pass/fail. The submitter is notified either way. Whether hiring requisitions are created immediately is a canvas choice, matching two real-world habits.

Pattern A: execute on the document (closer to most HR practice)

1. From Approval, draw two outgoing wires.
2. Pass → End.
3. Fail → End (mark as failed end).
4. Bind “Submit staffing request” to this published workflow.

After finish: a pass writes the document as awaiting execute; the submitter opens it and clicks Execute to create hiring requisitions. A fail shows not approved and the comments.

flowchart LR
  A[Submit hook starts workflow] --> B[Approval]
  B -->|pass| E[End]
  B -->|fail| F[End · failed]

Pattern B: create on pass

On the pass wire, add Confirm staffing request and create hiring requisitions (same logic as Execute on the document). The fail wire may add Return staffing request, or omit it (finish still writes not-approved).

flowchart LR
  A[Submit hook starts workflow] --> B[Approval]
  B -->|pass| C[Confirm staffing request]
  C --> E[End]
  B -->|fail| F[End · failed]

With no hooked workflow, HR still confirms or returns on the staffing-request document.

| | Content | |--|------| | Receives | Variable staffing_req_id (written by the submit hook) | | Writes | Pattern A: staffing_req_status awaiting execute or not approved; Pattern B also writes recruit_req_ids after confirm |

6.4 App work

Meaning: the workflow stops here and creates a work ticket; a colleague finishes in the linked app or plugin and marks complete; only then does the workflow continue.

How to set it up

App side: open the work ticket by work key → finish → call complete and bring results.

| | Content | |--|------| | Receives | The whole variable table on arrival (ticket may carry a snapshot); handler resolved from assignee variables | | Writes | Keys in complete-interface result that also sit in the result variable whitelist (if no whitelist, implementation accepts valid result keys) |

Example: employee onboarding

flowchart LR
  A[Assign account · app work] --> B[Issue supplies · app work]
  B --> C[End]

If HR Settings → Hire has “auto-start on close hire” checked, roster close, account, and supplies chain together. Injected variables: §4.4; how to build it: §7.5.

Template default result-key examples: mindlink_user_id, invite_email, bind_ok; supplies side e.g. issued_items, issue_note (the designer node config wins).

6.5 Agent work

Meaning: on arrival, automatically dispatched to a chosen work agent (not a streaming conversation). It can call tools to look up data and plugins; when done, JSON results write back to variables, then continue or branch pass/fail.

In conversation the same agent still streams one round of reply; on the workflow side it can run in parallel up to the agent’s workflow concurrent-run cap, with extras queued.

How to set it up

1. Add Agent work, select it, configure on the right.
2. Agent: a work agent in the workspace.
3. Task note: spell out what to do; use {{variable name}} (this is not the Notes field above).
4. To generate an execution-summary file: check Give this instance’s inspection results to the agent (must sit after Auto score).
5. Result variables / required result variables: whitelist and required keys. When generating files, write report_docx_upload_id, report_xlsx_upload_id, and similar.
6. Timeout minutes (optional; lengthen for Word/Excel/slides).
7. If you need branches, drag pass / fail wires.
8. On the agent edit page, set workflow concurrent-run cap (default 3).

The agent should end its reply with JSON, for example:

{"outcome":"pass","result":{"emp_title":"Engineer","department":"R&D"}}

| | Content | |--|------| | Receives | All keys in the variable table; the task note is {{…}}-replaced before enqueue and given to the agent. If “Give this instance’s inspection results to the agent” is checked, also attach the score summary and each item’s conclusion | | Writes | Keys in the result object that sit in the result variable whitelist; outcome affects the outgoing wire (pass/fail) and usually does not enter the business variable table |

Example: … → Agent work (look up job) → … Task note: Look up current job and department for {{display_name}} (employee number {{emp_no}}), write emp_title and department.

Example: generate an execution-summary file

The workspace must have Office documents (Word / Excel / slides) and Basic documents (web pages) enabled. Suggested canvas order: … → Auto score → Agent work (write summary) → Complete.

Task-note example:

From this instance’s completed inspection and scores, generate an execution summary for {{factory_name}}.
Use office-document tools for Word (.docx) and Excel detail (.xlsx); add slides (.pptx) or a web page (.html) if needed.
Do not deliver text only with no file. Write the upload_id the tools return into the result.

Result variables: report_docx_upload_id, report_xlsx_upload_id. The agent must use office_document (build_document / build_spreadsheet / build_presentation) or file_write (.html); do not write Office files from a script.

After “produce report” finishes, the handle page shows Execution summary: the report opens with the same preview as in conversation, or Open conversation to that agent record. Opening that agent, the conversation list has records marked Workflow. After the report, wire straight to End or a branch; do not add a “human confirm” form.

6.5b Call a workflow

Meaning: on arrival, start another workflow (e.g. remediation), mapping this instance’s variables to it. Default: this workflow continues after sending (does not wait). Fits opening a remediation case after CAP, or a make-up workflow after approval reject.

Config points

1. Target workflow: this workflow (run upload and score again for items that need fix), another enabled definition in the workspace, or a template code (e.g. cap_remediation). If unspecified, a remediation-style call node defaults to opening another instance of this workflow.
2. Start mode: continue after sending (default); wait until the other finishes (coming).
3. Input mapping: each row this-instance source => their variable; side channel can use source:cap_items (items needing improvement), source:aggregate_summary. A trailing ! means required.
4. How many instances: one for the batch, or one per item needing improvement.

| | Content | |--|------| | Receives | This instance’s variable table + (optional) packed score side channel | | Writes | called_instance_id / called_instance_ids, called_definition_id, call_mode |

The system automatically sends caller_instance_id and similar correlation keys to the other side. Contract details: workflow.json-v1 · workflow.call.

Example (IWAY): CAP remediation → Call a workflow (this workflow) → End or re-inspect. After submitting remediation notes, a new instance of this workflow opens with only the items that need fix.

6.6 Load inspection standards

Meaning: automatically read checklist items from the workflow’s bound compliance questionnaire, for later Upload evidence and Auto score. No user work item. This node is declared by the Compliance plugin; if compliance is off, it does not appear in the designer catalog.

How to set it up: bind a questionnaire in workflow Basic settings; place it on the canvas before upload/score; “phase filter” can load only some phases.

Older workflows that still write standards.load map at run time to compliance load (compliance must be enabled).

| | Content | |--|------| | Receives | The bound standard set; start info in the variable table (e.g. factory name) can be shown | | Writes | Checklist written to the instance payload (scoring basis); usually not as flat keys in variables |

6.7 Auto score

Meaning: score from each item’s scoring notes and uploaded evidence, then summarize. No user work item; results feed Rule branch.

How to set it up: after Upload evidence, before Rule branch; detail lives on compliance items.

| | Content | |--|------| | Receives | Checklist + uploaded evidence | | Writes | Score detail and summary (pass / red line / needs improvement) into the instance payload summary; Rule branch reads the summary, and generally does not depend on you creating same-name form variables |

6.8 Rule branch

Meaning: choose which later wire to take. No work item of its own. Note: Notes is only a remark and does not participate in branching.

#### A. By score summary (inspection style)

1. Add Rule branch, rule By score summary (pass / red line / CAP).
2. Drag up to three wires: pass → complete; fail (red line) → failed end; needs improvement (CAP) → remediation form then back to upload/score.

| | Content | |--|------| | Receives | Previous Auto score summary status (payload side) | | Writes | None; only chooses the outgoing wire |

flowchart LR
  S[Auto score] --> B{Rule branch}
  B -->|pass| OK[End]
  B -->|fail| NG[End · failed]
  B -->|needs improvement| R[Remediation notes · form]
  R --> U[Upload evidence]
  U --> S

#### B. By variable range (e.g. several amount bands)

Fits 4+ way splits such as “under 100 → A, 100–200 → B, 200–500 → C, 500+ → D”.

1. An earlier Fill a form must have a comparable number: a number field (e.g. amount), or a line-item column with sum (or similar). After submit, that writes tableKey.columnKey (e.g. expense-line amount total → expense_lines.amount).
2. Add Rule branch, rule By variable range.
3. Pick the variable; in the range list click “Edit in dialog…” for each band’s display name and bounds (lower inclusive, upper exclusive). When wiring, pick the band name from the dropdown; no hand-written codes.
4. Drag as many wires as ranges; each outgoing wire picks the matching range label.
5. “When unmatched, take” defaults to Unmatched (other): drag one more wire and set its condition to “Unmatched (other)” (empty, illegal number, or outside every range). You can also send unmatched to a specific band.

flowchart LR
  F[Fill form_total amount] --> B{Rule branch_variable range}
  B -->|lt_100| A[Path A]
  B -->|r_100_200| Bpath[Path B]
  B -->|r_200_500| C[Path C]
  B -->|ge_500| D[Path D]

“By total-score threshold” is still in development.

6.9 End

Meaning: workflow terminus. You can have several end nodes (e.g. “closed” and “failed”).

How to set it up: titles that distinguish purpose; on a fail outcome check Mark as “failed” end; cannot be set as start.

| | Content | |--|------| | Receives | All variables and payload on arrival (available for later review) | | Writes | None; instance status becomes completed or failed |

6.10 Node variable cheat sheet

7. Getting started and business examples

7.1 Example A: blank workflow as a leave request (shortest path)

1. New Blank workflow
2. On the Start form add fields: reason, days, approver (key implies user-id semantics)
3. Add Approval, handler → Form variable → approver_user_id
4. Add two End nodes: “Passed” and “Rejected”
5. Dual wires from approval to the two ends, outgoing pass / fail
6. Save → start a self-test under Run

7.2 Example B: IWAY factory audit (inspection style)

1. Create from the IWAY factory audit template
2. In Basic settings, bind a compliance questionnaire (items maintained in Compliance)
3. Tweak the designer if needed; scoring and branches usually stay default
4. Under Run, pick a department if prompted, upload evidence, then watch work items and scores

7.3 Example C: only change the approval chain

Copy an existing definition → insert a second Approval after the first → handler a different variable or employee → save. Fits two-level “department lead → finance”.

7.4 Example D: expense (header + line items + finance handle)

This is a test example assembled from generic nodes, not a built-in “finance-only node”. Finance uses App work (same class as issuing supplies on hire).

1. Create from Blank workflow
2. Fill a form (start): department, date, expense lines (line-item table + amount total), receipt attachments, notes
3. Rule branch (optional): band by expense_lines.amount to different approvals
4. Approval (lead / manager)
5. App work (finance expense, test-example config):

1. End

flowchart LR
  A[Fill expense form] --> B{Amount bands}
  B --> C[Approval]
  C -->|pass| D[App work · finance expense]
  D --> E[End]

Today (plugin not ready): the finance handler opens the work item on the Run page and taps Mark handled to continue. Once a plugin is ready: the plugin opens the work ticket by work_key → fills the voucher → calls complete; Run page “Open app” deep-links to the plugin. You do not change the node type.

You can also use a second Fill a form / Approval instead of app work (pure human confirm), but that cannot take a future finance plugin’s work tickets.

7.5 Example E: employee onboarding (account + supplies)

1. New workflow from template Employee onboarding (or build from blank):

- App work assign_mindlink_account (plugin: HR) - App work issue_assets (plugin: Warehouse) - End

1. Under HR → Settings → Hire, check “auto-start on close hire” and pick that workflow; optionally name a warehouse handler. Leave / transfer are configured in the same Settings (off by default)
2. Closing hire starts it automatically; an admin finishes account assignment in “Settings → Hire”; warehouse deducts stock and completes the ticket under Apps → Warehouse → issue work items

Auto-injected employee fields: §4.4. If step 1 is Agent work instead, the task note can use {{display_name}}, {{emp_no}}, and similar directly.

7.6 Combination cheat sheet

8. Save, run, and publish

1. Workflow design → save the canvas
2. Basic settings → name, notes; IWAY-style must bind a compliance questionnaire
3. Run → fill start info, produce an instance (or HR close auto-starts)
4. (Optional) Publish to the app desktop → front-line enters from a desktop icon

8.1 Trial highlight (designer structure check)

On the left of Workflow design, click Trial highlight: structure-check the current canvas (including unsaved edits). Nodes and wires light along the main path step by step.

• OK lights through to an end node; prompt “main path can complete”
• Blocked stops at the obstacle (missing wire, missing approval branch, no agent chosen, …) and shows why
• Does not actually start a workflow or assign work items

Main path: prefer “Next”; approval / rule branch take the “Pass” wire. After the check, Clear highlight and keep editing.

Split from “test instances” below: trial highlight checks that the design connects; Start as a test is what verifies real handling and variable write-back.

8.2 Test instances (self-test, then clean up)

After structure passes, run a test instance before giving front-line a formal one:

1. Open Run, check Start as a test
2. Fill start info and submit as usual — real work items/tickets are created; titles get a “[Test]” prefix
3. Walk approval, agent work, and similar; confirm branches and variables
4. The list can filter “All / Formal only / Test only”; Clean up test instances hard-deletes cleanable test instances of this workflow (ones you started; a workspace admin can clean all test instances of this workflow) plus their work items, tickets, and agent tasks

Instances auto-started by HR close, or started by a plugin/conversation tool, default not test instances. Clean-up is irreversible; formal instances are untouched.

9. FAQ

Q: If I change the design, do in-flight instances change? No. Only instances started after save.

Q: Where do I look up variables passed in from hire? The config list is §4.4. After a run, look at variables in that instance API response, or reference the same keys in later forms / agent task notes.

Q: How do I know what a node wrote? See that node type’s notes (§6) and the field keys / result variables on the node; after handling, check the instance variables.

Q: What is the difference between approval and a “signature field” on a form? Approval is its own step, with pass/reject semantics and branches; a form signature is only a field and does not fork on its own.

Q: App work finished but the workflow does not move? Check the work key matches what the app pulls, the handler received the work item, the complete API succeeded, and required result variables were actually returned.

Q: Agent work did not pick up variables? Confirm they are in the task note (not Notes above), and {{variable name}} matches keys already in the table when that step is reached (hire scene: §4.4).

Q: Rule branch always takes the same wire? Notes does not participate in branching. Score mode: confirm Auto score already ran, and outgoing wires are pass/fail/needs improvement. Variable-range mode: check the variable, range bounds, and outgoing band names. Multi-band split: §6.8 B.

Q: Why does a blank workflow have no checklist? The blank template only gives “Start → Complete”. For inspection capabilities, enable compliance and add “Load inspection standards / Upload / Score” yourself, or use the IWAY template.

Q: Delete will not remove a node? That is the start. Move start to another node, then delete.

10. Implementation map

Core fields of the designer product:

• start_step: start node id
• steps[]: each step’s type, title, fields, config
• transitions[]: explicit wires (when: always / pass / fail / cap_required, or custom when for variable ranges)
• layout.nodes[]: canvas coordinates; editor display only

Conversation tools (work agent): workflow_list / workflow_create / workflow_start can help create and start.

Other docs: help/product-features/compliance-workflow.md (product capabilities and template overview).

Wrap-up

Getting started: draw the shortest path on a blank workflow → trial highlight → start as a test → clean up test instances → then add approval, app work, or inspection nodes as needed. Complex audits use IWAY + compliance items. Onboarding chain uses the Employee onboarding template + HR settings. Variables: at design time, field keys / result variables / §4.4; at run time, instance variables and the §6 node in/out table.