W
Walnut Peafowl
Before the Processes overhaul, the API allowed a run's task names to be
updated after kickoff. That made the natural workflow possible: kick off a
template, then fill in the specifics for that particular run — the names,
systems and items the checklist actually refers to.
On 2.44.0 that is refused:
PUT /api/v1/procedure_tasks/{id}
{"procedure_task": {"name": "..."}}
422 {"error":"Validation failed","details":["cannot modify structural
fields (name) on run tasks. Only assigned_users, due_date, priority,
user_id, completed, completed_at, completion_notes can be updated."]}
There is also no way to supply values AT kickoff, so a template task
written as
"Add to distribution lists: $Variable"
can only ever be kicked off with the literal placeholder still in it.
With both routes closed, the only workaround is to clone the entire
template per run: read the template's tasks, substitute values, create a
fresh procedure, create every task on it, kick THAT off, then archive the
clone so the company's process list doesn't accumulate one throwaway
template per run. Archiving the clone then makes every run display "From
archived process" and nest under a discarded parent, which looks broken to
anyone opening it. Clearing and reusing a single copy instead requires
DELETE on /procedure_tasks, a separate API-key permission — without it, the
clutter and the badge are unavoidable.
We understand the lock is deliberate — the error calls these "structural
fields", and freezing a run's shape mid-flight is reasonable. The ask is a
scoped exemption rather than reverting it. Any ONE of these would work:
1. POST /procedures/{id}/kickoff accepting a variables map, substituted
into task names as the run is created. Best fit: it matches how people
already write templates with placeholders, and the run is still frozen
the moment it exists.
2. Allow name edits on a run for a short window after kickoff, or only
while the run has no completed tasks.
3. A "template" flag on procedures that hides them from the company's
process list, so a per-run source can exist without being archived.
Use case: generating a checklist whose tasks name the specific items for
that run, rather than kicking off a generic template and leaving the reader
to work out which parts apply.