Start a workflow from a form

Forms and configurationDashboardHTTPMCPx-lt-widget: invokex-lt-invokeinputSchemax-lt-bindGET /api/workflows/invocable

A control on a work form starts another workflow with values mapped from the record, under the same per-caller list and input gate.

The situation

A packer working an order needs to reprint its label. The reprint is its own workflow with its own form. The packer should start it from the order’s screen with the order already filled in, and only if they are allowed to run it.

The recipe

"reprint_label": {
  "type": "string",
  "readOnly": true,
  "x-lt-widget": "invoke",
  "x-lt-invoke": {
    "workflow": "reprintLabel",
    "data": { "order": { "id": "{{metadata.orderId}}" }, "copies": 1 },
    "metadata": { "escalationId": "{{escalation.id}}" },
    "modal": true
  },
  "title": "Reprint label",
  "x-lt-section": "Tools",
  "x-lt-showIf": "metadata.orderId"
}

modal: true opens the workflow’s own invoke form (its inputSchema) in a dialog, prefilled by inverting each field’s x-lt-bind. Without it, the control posts data at once, optionally behind a confirm prompt. Tokens keep their types: a number stays a number, and a missing value omits the key so the workflow’s defaults apply. The run’s outcome arrives on the control over the same live events the Invoke Tool page follows.

The guarantee

The control renders only for workflows the signed-in user may invoke, read from the same per-caller list as the Invoke Tool page, and the server runs the same predicate on the post. The payload meets the workflow’s input_schema gate, with the canonical 422 listing each violation. The field is display-only: it is dropped from the resolver payload and never belongs in required. See Forms.

Forms and configuration