A workflow stalls at a human step. Somewhere, an approval is waiting on you.
You just don’t know it. It’s a card in a chat thread you already scrolled past, or a row on a runs canvas nobody opens unless something breaks. Meanwhile your actual task board, the one place you check for “what needs me now,” says nothing. The work is stuck, and the one screen built to tell you that is silent.
That gap is closed. A workflow that needs a person now shows up as a task in that person’s queue. Close the task, the workflow continues. No second inbox. No screen to remember to check.
Same fact, read from two directions
There’s no new store behind this. Your tasks stay in one place, workflow runs stay in another, and the two join through a tag pinned to the task the moment a run parks: which run, which step. That’s it. Either side can find the other by it; neither needs to know how the other one is built.
workflow parks at a human step
│
▼
a task appears on your board
(tagged with the run + step)
│
┌──────┴──────┐
▼ ▼
close it on resolve it from
the board chat, Telegram,
or the run monitor
│ │
└──────┬──────┘
▼
both surfaces agree — no card
left saying "waiting on you"
for a decision already made
Whichever door you use first wins. Approve from the board, and the run moves on. Reply “approved” to the chat card instead, and the task on your board closes itself, decision noted, so it never sits there stale pretending you still owe someone an answer.
The task board already had the job
We didn’t build an approvals screen, a second queue, or a new page. The task board already answers “what needs me now” — a paused workflow just needed to speak that language. So a run-lane task looks like any other task, with one difference: a small workflow chip that tells you where it came from, and a “View run →” door if you want to see the whole flow before you decide.
Reassign it like any task, too. Hand it to a teammate and the run doesn’t need to know or care — it resumes on whoever’s word closes it, not on who it was first assigned to.
One honest edge, on purpose
Archiving a run-lane task rejects its run. That’s not a bug we’re disclosing reluctantly, it’s the correct behavior, stated plainly. A task closing is what tells the workflow to continue or stop, and archiving is a close. Archive an approval task to tidy your board and you’ve just told that workflow no. Want it off your board without deciding anything? Open the run and act there instead of hitting archive.
We’d rather tell you that than let you find out the hard way.
What’s actually true today
- Every human step a workflow parks at writes a task, tagged and deduplicated — a re-parked step never spawns a second card.
- Closing that task, from the board, dispatches the run’s resolution in-process.
- Resolving the run from anywhere else (a chat card, a Telegram button, the run monitor) closes the matching task to match, decision noted.
- Reassignment and comments work exactly like they do on every other task, because it is one.
- A round-trip test proves the whole loop (park, task appears, close, run resumes, resolve from elsewhere, task closes) and runs green before every ship.
Nothing here needed a new inbox, a new database, or a new page. It needed the two things you already had — your task board and your workflow runs — to finally agree on what “waiting on you” means.
Next time a flow needs you, you won’t find out by accident. You’ll find it where you already look.