Part 2 of our Workflows Unleashed series. This week: how we built an editor that's visual without being simplistic.
Most automation tools make you choose. Either you get a pretty interface that can't handle real complexity — five actions maximum, no branching, export to YAML if you want anything serious. Or you get a powerful scripting engine wrapped in a developer-only CLI that requires you to memorise fifty configuration keys.
We refused to choose.
Flomation's editor is a canvas. You drag nodes onto it — triggers, actions, outputs — and connect them with edges. Each node is configurable: typed inputs, dropdown selects for options, variable references for dynamic values, and structured outputs that flow downstream.
It looks like a flowchart. It behaves like one too. Data enters at the trigger, flows through each action in topological order, and exits at the output. You can trace the path of any value by following the edges.
But unlike a flowchart, it executes. Every node in the graph corresponds to a compiled action in the executor. When a flow runs, the engine walks the graph, resolves variable references, executes each action with its resolved inputs, and passes the outputs to the next node.
Simple pipelines — trigger → process → output — are table stakes. The real test of a visual editor is how it handles complexity.
Conditional branching. The If node evaluates an expression and routes execution down the true or false path. The Switch node does the same with unlimited output handles — one per case — with support for equals, contains, starts_with, ends_with, and regex operators.
Loops. The For node iterates a fixed number of times. The While node iterates until a condition becomes false. Both expose the current iteration index and support nested loops. Inside a loop, every child node re-executes with updated context on each pass.
Error handling. The On Error node catches failures from any upstream action. When an action throws an error — a database query fails, an API returns a 500, a timeout expires — execution routes to the On Error path instead of halting. From there, you can log, notify, retry, or fall back to an alternative.
Parallel paths. When a node has multiple children, they execute in dependency order. Independent branches can run concurrently. The graph structure itself defines the execution plan — no configuration required.
Variable substitution works everywhere. Any input field accepts ${node.output_name} references, ${secrets.API_KEY} for encrypted values, ${env.BASE_URL} for environment variables, and ${flow.trigger_data} for trigger payloads. The executor resolves all references before passing inputs to the action, regardless of whether the input type is string, integer, boolean, or object.
Node configuration persists. When a flow author sets a value on a node — a Slack channel, an API endpoint, a database connection — that value stays set. When the flow runs as part of a tool chain (for example, called by an AI action), pre-configured values are protected from being overwritten.
Revision history is automatic. Every time you save, the entire graph is stored as an immutable snapshot. There's no "save as" or "create version" — every save is a version. When you inspect a past execution, you see the flow as it was when it ran, not as it is now.
A webhook that receives a JSON payload, validates a required field, writes a record to PostgreSQL, and sends a Slack notification with the result.
A cron job that runs every hour, queries a MySQL database for stale records, archives them to S3, and posts a summary to Discord.
A Git-triggered pipeline that fires on every push, runs a Bash script, and posts the output to Telegram.
All three are under ten nodes. All three are production-ready the moment you save them.
We'll cover the 80+ actions that make all of this useful — and why purpose-built integrations beat generic HTTP wrappers every time.
www.flomation.co - free to start, no credit card.