How it works
How a message moves through a workflow, what each step receives, and what gets recorded.
Flowblocks has three parts: a builder for drawing workflows, a runtime that executes them on the server, and a stored history of each run.
The graph
Steps are the nodes and connections are the edges. Start receives the chat message. Each step then runs in order, following the connection you drew out of it, until the run reaches End.
Most steps have one way out. A branch has several, and chooses which one the run continues along:
| Branch | Paths | Chosen by |
|---|---|---|
| If / else | True, False | A CEL expression |
| While | Loop, Done | A CEL expression, checked each time around |
| Guardrails | Pass, Fail | A check on the message |
| Human approval | Approve, Reject | A person |
Runs
A run starts when a message arrives. Each step receives the previous step's result, does its work, and hands its own result to the next. Steps that call a model stream their text as it is generated.
A run ends when it reaches End, when a step fails, or when it hits a limit: 20 step visits, or the token budget.
Run history
For each step of each run, Flowblocks stores what went in, what came out, how long it took and whether it failed. You can read it in the Runs tab.
Access
A workflow can reach only the services someone has connected, and a step can call only the tools selected on it. Tokens for connectors and MCP servers are encrypted before they are stored and are opened only when a step needs them.
Hosting
On Flowblocks Cloud, the runtime is hosted for you. You can also run it yourself against your own Postgres database.