Yes, I have implemented HITL. There's a task queue(psql skiplock). You make a request (insert row). It builds a "workflow graph" of your request and compiles it, a combination between a FSM and graph program. It runs an iteration on the workgraph, and then if successful, submits the next step in the queue as "pending". the user then inspects and accepts the tasks, which then run another iteration of the workgraph. If…
Ask HN: How have you implemented human-in-the-loop workflows?
11–15 of 15 posts
Re: Ask HN: How have you implemented human-in-the-loop workflows?
#12Would it help to think of it as two workflows? The first workflow ends with a human. The second workflow is triggered by the human. To build those two workflows, use whatever tools allow you to build such no-human-in-the-loop workflows.
Wouldn't you want to track the flow through the all components though? Case management for example - case is created, case is triaged, case is (hopefully) closed. That way there is visibility. If it's workflow A/tool A, some human using tool B, and then workflow C/tool C, absent integration you lose external visibility at each step, or you have to go check in Tool A to see if work flow made it to Human, and so on.
Re: Ask HN: How have you implemented human-in-the-loop workflows?
#13Yes, I have implemented HITL. There's a task queue(psql skiplock). You make a request (insert row). It builds a "workflow graph" of your request and compiles it, a combination between a FSM and graph program. It runs an iteration on the workgraph, and then if successful, submits the next step in the queue as "pending". the user then inspects and accepts the tasks, which then run another iteration of the workgraph. If…
is the "workflow graph" entirely custom built or is there a library/framework/service for it? Would love to hear more