workflow_update
Edit a workflow's fields or its definition graph: every call re-validates the definition — yours if resent, else the stored one decoded back — against the resulting trigger_type, so a plain rename can fail if that stored graph no longer validates, and flipping to 'schedule' without a schedule block fails here rather than at the scheduler. When trigger_type ends as 'schedule' and is_active as 1, next_run_at recomputes from schedule and now on every call, even one touching neither field; any value you send for it is ignored. Optional expected_updated_at compare-and-set: a stale value refuses CONFLICT — re-read, merge, retry. NEXT: workflow_read to confirm the new next_run_at.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The workflow id (workflow_list shows them). | |
| name | No | ||
| is_active | No | ||
| role_name | No | ||
| description | No | ||
| next_run_at | No | ||
| trigger_type | No | ||
| imported_from | No | ||
| definition_json | No | ||
| expected_updated_at | No | Optional compare-and-set guard: the updated_at from a prior workflow_read/workflow_list. Mismatch returns CONFLICT with the current value. |