Workflows that stop for a person, and write down what happened.
Build the graph, choose the step where judgement is worth waiting for, then publish it. Four ways to start a run, two branches out of every human step, and a stored record of what each node received and returned.
In short
- A workflow is a graph of nodes that the engine runs in dependency order.
- Every workflow keeps two copies: a draft you edit and a live version the engine runs.
- A run starts from a schedule, an inbound webhook, the trigger form, or Butter in chat.
- A human step parks the run and holds its output open until a person approves or rejects it.
- Every node execution stores what went in and what came out.
What is a workflow in HumanIn.Ai?
A workflow is a graph of connected nodes that the engine runs in dependency order. Nodes call AI, fetch data, post to systems you already run, or stop and wait for a person. Each workflow keeps a draft you edit and a published version the engine runs, so editing is never the same as changing what is live.
Nodes pass values along their connections. A node runs once everything feeding it has produced a value, which means two branches that do not depend on each other run at the same time rather than one after the other.
One node type behaves differently. A human step produces nothing on its own. When the run reaches it the engine serialises the state, marks the run Awaiting human review, and stops. It stays stopped, for as long as it takes, until someone opens the output and picks a branch. Nothing times out, and nothing proceeds on a guess.
Steps that talk to your own systems are custom nodes, defined once and reusable across every workflow in the organisation.
Build it, run it, sign it, look it up.
A workflow is not a script you fire and forget. It is a circuit, and the interesting part is the station where it stops and waits for you.
Build
Drag nodes onto the canvas and connect them. Triggers, AI steps, human steps, publishing steps, and any HTTPS endpoint you already own.
Visual builder. Custom nodes. Draft mode with autosave.
Run
A run starts on a schedule, from a signed webhook, from the trigger form on your home screen, or because you asked Butter. It is queued, then each step executes in order.
Schedules with timezones. Webhook URLs. Anywhere Input.
Decide
At a human step the run parks and holds its output open. Read it, edit it, then approve or reject. The run resumes down the branch you picked.
Review queue on web and phone. Editable output. Push.
Look back
Every node execution stores its input and its output, with a duration. Filter the history, watch runs arrive live, and cancel one that is still going.
Run history with filters. Per node input and output.
And the loop answers back. Butter sits in your chat, and on the agents page you choose which of your own workflows it is allowed to run.
Editing is not the same as shipping.
Every workflow keeps two graphs. The draft is yours to break: drag nodes around, rewire it, rename things, and it autosaves as you type. The live graph is what the engine actually runs, and it only changes when you press publish.
Publishing snapshots the version it replaced, so what changed and when is recorded.
The run stops and waits for you.
A human step is a node like any other, except it produces nothing until a person acts. The engine saves the run's state, marks it awaiting review, and leaves the output open for editing. Two branches leave the step, and your decision picks which one the run takes.
A parked run holds indefinitely. Nothing times out and nothing proceeds on a guess.
What actually changes.
Three jobs that already happen at your company. Every step in the after column is a node that exists today.
| Scenario | Before | After | What changes |
|---|---|---|---|
| The weekly post nobody wants to write | Someone remembers on Thursday. They scroll back through the week, work out what is worth saying, write it, get it read by one other person over chat, then paste it into LinkedIn and hope the formatting held. | A Scheduled Trigger fires on Thursday morning. An AI step drafts the post against a Custom Template so the output has the fields you expect. A Human Loop step parks the run and puts the draft in your review queue. You edit the wording and approve. The LinkedIn node posts it and returns the live URL. | The writing is already done when you open it. Your job is the read and the sign off. |
| Tickets that arrive faster than anyone reads them | The helpdesk fills up overnight. Someone opens each one, works out what it is about, decides whether it is urgent, and either answers it or moves it. The judgement is easy and the volume is the problem. | Your helpdesk posts to a Webhook Trigger the moment a ticket lands. An AI step reads it and drafts a classification and a reply. A Human Loop step parks anything it is unsure about. You approve or reject, and a Custom Node writes the outcome back to the helpdesk over your own API. | You read decisions rather than tickets, and only the ones that needed a person. |
| A morning brief assembled from four places | Someone checks the forecast, pulls yesterday's numbers out of one system, the open jobs out of another, and pastes it all into a message before anyone starts work. It takes twenty minutes and it happens every single day. | A Scheduled Trigger runs before the shift. The Weather node pulls the forecast for each site. Custom Nodes fetch yesterday's numbers and the open jobs from your own systems. A Combine node merges them into one object, an AI step writes the brief, and a Human Loop step puts it in front of you before it goes anywhere. | The assembly happens without you. You still decide whether it goes out. |
- LinkedIn Pages
- Any HTTPS endpoint
- Inbound webhooks
- Your own API keys
Everything a workflow touches.
Nine pages rather than one, because each of these is a real surface with real limits worth reading before you build on it.
- Workflow builder — The canvas, inline editing, autosave, and the publish step.
- Custom nodes — Your own endpoints as ordinary steps, defined once, reused everywhere.
- Agents and tools — Choose which of your workflows Butter is allowed to run.
- Butter — An assistant in your chat that proposes runs and waits for approval.
- Messaging — Direct messages, groups, threads, and approval cards in the transcript.
- Run monitoring — Live status per workflow, the trigger form, and full run history.
- Library — Files with signed uploads, and the record of what each step received.
- Mobile app — Start runs, approve them, and keep up with chat, from your phone.
How does a run actually start?
Four ways. A Scheduled Trigger fired by a poller that checks every sixty seconds. A Webhook Trigger with its own unguessable URL, which an external system posts to. The trigger form on your home screen, where you fill in the inputs by hand. Or Butter, in chat, proposing a run that you approve.
What happens when a node fails?
The run is marked failed and the failing node is named in the error. Branches that do not depend on the failed node keep running, so a workflow does not lose work it had already finished. There are no automatic retries: a failed run stays failed until you start another one.
Can I roll back to a previous version?
Every publish snapshots the version it replaced, so the history exists. There is no rollback button today. What you can do is switch to Draft, make the change you want, and publish again.
Who can see and run a workflow?
Workflows belong to teams. One with no team assigned is visible to the whole organisation; one assigned to teams is visible to those teams' members plus organisation admins. Within a team, users can view and run, engineers can also edit and delete, and leaders can additionally reassign teams.
Can I cancel a run that is already going?
Yes. Anything queued, running or awaiting review can be cancelled from the run history, one at a time or several at once. A cancelled run shows as failed with "Cancelled by user" as the reason.
Build one loop and see.
The free plan runs the whole product. Build a workflow, put a human step in it, and approve it from your phone.
No card. Your data stays in your organisation.