Every automation tool sells the same picture: you set it up once, and then it runs without you. It is a good picture. It is also the wrong goal for most of the work a small team actually wants to automate.
Consider chasing an unpaid invoice. Ninety percent of it is mechanical — find the overdue ones, look up the contact, draft a reminder, log that it was sent, schedule the next one. But there is one step in the middle that is not mechanical at all: should we actually send this to this customer, today? The answer depends on things no rule captures. They emailed last week promising payment. They are about to sign a bigger contract. Their finance person is on leave and everyone knows it.
Automate that step and you get an automation nobody trusts, which means an automation nobody turns on.
The trap of all-or-nothing
Faced with this, most teams pick one of two bad options.
They automate everything and then quietly stop using it, because the first time it sends something embarrassing they lose confidence in the whole thing. Or they automate nothing, because the one judgement call in the middle makes the whole workflow feel too risky to hand over.
Both are the same mistake: treating the workflow as one indivisible decision about trust, when it is actually nine steps that need no judgement and one that does.
Pausing is a first-class step
The version that works keeps a person in exactly one place. In Flowversal that is an approval block: you drop it into the canvas like any other step, and when the run reaches it, it stops.
Not "fails and you restart it later" — stops. The run holds its state, whoever you nominated gets asked, and the workflow sits there. For ten minutes, or for four days. When they answer, it continues from that exact point with everything the earlier steps produced still in hand.
That distinction matters more than it sounds. A workflow that has to be restarted after a human check is not really one workflow; it is two, with a manual handoff in the middle, and the handoff is where things get dropped. A workflow that genuinely suspends is one thing that happens to involve a person.
What this changes about how you build
Once pausing is cheap, you design differently.
You automate the boring nine steps immediately instead of waiting until you trust the tenth. The value arrives now, and the risky part is still a decision someone makes.
You put the approval where the irreversible thing happens, not at the start. Ask about the specific email that is about to go out, with its actual contents visible, rather than asking "shall I run the invoice chaser?" before anything has been drafted. A person approving a concrete artefact catches mistakes; a person approving an abstraction just clicks yes.
You can remove it later. After a hundred runs you may find the judgement call was more mechanical than you thought, and the conditions can be written down. Then delete the block. Starting with the human in place and removing them is a much better path than the reverse, because the reverse requires an incident first.
Where else a person belongs
Approval is the obvious one, but the same idea covers more than a yes/no.
A form step pauses and asks for information the workflow cannot derive — which of these three suppliers, what budget code, what should the subject line say. A wait-for-event step pauses until something happens outside the system entirely: a contract is signed, a payment clears, a shipment scans.
All three are the same shape. The run is not failing. It is waiting, on purpose, for the world to catch up.
The honest summary
"Fully automated" is a good demo and a poor design principle. The work that is genuinely worth automating usually has a person in it somewhere — and the tools that pretend otherwise are asking you to choose between an automation that is unsafe and no automation at all.
Keep the person. Automate everything around them.