Workflow builder: how you actually build one
The four building interfaces compared on what using them feels like, the parts every builder makes awkward, and what determines whether what you build survives contact with reality.
Rithul Palazhi10 min read
On this page
Comparisons of workflow builders describe what each can do. The thing that actually determines whether you finish what you started is what using it feels like on the third hour of a Tuesday, when the process has turned out to have an exception nobody mentioned and you are trying to express it.
This page is about that: the four building interfaces and how each behaves, the parts of a workflow that every builder makes awkward, and what separates something that still works in six months from something abandoned. For evaluating a platform at organizational level, see workflow automation platform.
What we'll cover
The four ways of building
Form-based. A sequence of configuration screens: pick a trigger, pick an action, map the fields, add another. No canvas and no code. Genuinely easy for the first automation and it becomes unwieldy as steps accumulate, because there is no way to see the whole thing at once. Branching, where it exists at all, tends to be expressed as conditions attached to steps rather than as visible paths.
Visual canvas. Nodes and connections laid out on a surface, with branches drawn as branches. The substantial advantage is that the structure is visible, which makes complex logic far easier to reason about and to hand to a colleague. The cost arrives with size: a canvas of forty nodes needs scrolling and zooming to comprehend, and the tidiness of the layout starts to matter in a way that has nothing to do with the work.
Code. Writing the steps directly. The most expressive option, the best supported by version control and testing, and available only to people who can write code. For anything with genuinely complicated logic this is often the least frustrating route, which is why technical teams keep returning to it.
Conversational. Describing the process in plain language and having the platform build it. What changes is who can build: the person who understands the process no longer has to translate it through someone who understands the tool. The output is a real automation you inspect and adjust, rather than a chat transcript.
Nobody is obliged to pick one permanently. The useful question is which suits the process in front of you and the person who will maintain it, and mixed approaches are normal.
The parts every builder makes awkward
These are the things that turn a twenty-minute build into an afternoon, regardless of which interface you chose.
Data that is nearly the right shape. The date arrives as a string in an unhelpful format, the amount includes a currency symbol, the name is one field here and two there. Reshaping data between steps is the majority of real building effort and it is the part every demonstration skips.
Lists. Handling one record is the easy case every tutorial shows. Handling an order with six line items, each needing its own processing, is where builders diverge sharply in quality. If your process involves lists, test that specifically before choosing.
Conditions that are not binary. "If the customer is enterprise, unless the order is under a threshold, in which case treat it as standard, but flag it if they asked for expedited delivery." Real processes accumulate clauses like this, and expressing them is where form-based builders fall over and canvases become sprawling.
Errors. What happens when step four fails. Most builders make the happy path pleasant and error handling an afterthought, which is exactly backwards for anything you intend to depend on.
Waiting. Processes that pause for an approval, or until a date, or until something else completes. Support for this varies enormously and it is rarely prominent in marketing.
Testing with real data. Running the workflow against a genuine example without causing the real effect. Where a builder makes this difficult, people test in production, which is how a test email reaches four hundred customers.
Building something that survives
Write the process down before opening the builder. In sentences: what starts it, what information is needed, where that lives, what the decisions are, what the output should be, and what the exceptions are. Fifteen minutes here saves considerably more, and on a conversational builder this description is the input rather than a preliminary step.
Name things for the next person. "Check if customer is on enterprise plan" rather than "Condition 1". This is free at the time and it is the difference between a workflow somebody can pick up and one they rebuild rather than try to understand.
Handle the exceptions explicitly. The empty field, the duplicate, the record that arrives twice, the value nobody anticipated. A workflow that only handles the expected case will encounter the unexpected one within a fortnight.
Decide what happens when it cannot proceed. Stop and notify, skip and log, or retry. All three are defensible and having no answer means the default applies, which is usually to fail silently.
Keep each workflow to one job. A workflow doing three related things is harder to test, harder to change, and produces failures where you cannot tell which part broke. Several small automations beat one large one for everything except the number of items in a list.
Leave a note about why. The reason a step exists is invisible six months later. A sentence explaining why the threshold is what it is saves the next person from changing it and finding out.
Testing before you rely on it
Run it on real historical data. Take examples from the past where you know what should have happened, and compare. This finds more than any synthetic test.
Test the exceptions specifically. Feed it the empty value, the duplicate, the unusually large record, the one with the apostrophe in the name. These are what will actually arrive.
Break the connections. Revoke a credential and watch what the workflow does. Take a downstream system offline. How it behaves under failure is what you will live with.
Run it alongside the manual process for a cycle. Compare the outputs. Differences in this window are usually genuine discoveries about the process rather than bugs, and they are worth understanding before you switch over.
Check the volume case. Something that works on one record may behave differently on two hundred, particularly around rate limits and timeouts.
How builders differ on changing things later
Processes change, and a builder that made the first build pleasant can make the tenth change miserable.
Can you see what changed? Version history on automations, ideally with a diff. Without it, "this worked last week" is unanswerable.
Can you change it safely? Somewhere to test a modification that is not production. Editing a live workflow and hoping is common and unpleasant.
Can somebody else change it? The person who built it will eventually be unavailable. Whether a colleague can open it, understand it, and modify it correctly is the property that determines whether the automation survives.
How much does a small change cost? Adding a field to a form-based sequence may mean re-mapping several steps. On a canvas it may mean rearranging. Described in plain language, it is a sentence. This difference compounds over the life of an automation, and it is where conversational building has its clearest advantage: the description stays the artifact, so changing what it does means changing what you said.
That is the model on CodeWords: you describe the process and Cody, the automation builder, builds it, connects it to your systems, and deploys it, and when the process changes you describe the change. Automations connect to more than 3,000 integrations. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Templates, and when to start from one
Most builders offer templates, and they are more useful for learning than for building.
As a way of seeing how something is structured, a template is excellent. Opening one that does roughly what you want and reading how it handles triggers, data mapping, and errors teaches the platform faster than documentation does.
As a starting point for your actual process, they are frequently a trap. A template embodies assumptions about a generic version of the process, and yours differs in ways that matter. Adapting somebody else's structure to your exceptions is often more work than building from your own description, and it leaves you with logic you did not choose and do not fully understand.
The exception is a genuinely standard process. Some things really are the same everywhere: a form submission creating a record, a file arriving triggering a notification. For these a template is a reasonable and quick foundation.
Read a template before running it. Templates connect to systems and act on data, and one taken from a public gallery will do whatever its author configured. Understanding what it touches before granting it access is a reasonable precaution and rarely taken.
The related habit worth adopting is keeping your own templates. The second time you build something structurally similar, save the pattern. An internal library reflecting how your organization actually works is worth considerably more than any public gallery, and it accumulates without anyone planning it.
Frequently asked questions
Which builder is easiest for a beginner?
Form-based builders are easiest for a first simple automation, and conversational builders are easiest for a first complicated one, because the difficulty in a complex process is expressing the logic rather than operating the interface.
Do I need to understand APIs to build a workflow?
Not on no-code and conversational builders for common systems, where connections are handled for you. Some understanding helps when something goes wrong, and knowing that a service has a rate limit explains a class of failure that otherwise looks random.
How long should building a workflow take?
A straightforward two-system automation is minutes to an hour. Something with branching, exceptions, and data reshaping is realistically a day including testing. If a simple process is taking days, the builder is fighting you and that is information.
Can I move a workflow to a different platform?
Rarely without rebuilding, since each platform expresses logic in its own format. What transfers is the description of what the process does, which is why keeping that written down is worth the effort independently of any migration.
What is the most common mistake?
Building only the happy path. The workflow works beautifully on the example used to build it and meets its first unusual record within days. Time spent on the exceptions is better spent than time spent on the main path.
Should the person who owns the process build it?
Where possible, yes. They know the exceptions, they notice immediately when something is wrong, and they can change it when the process changes. The historical reason this did not happen was that building required skills they lacked, which is precisely the constraint conversational building removes.
How do I stop a workflow becoming something only I understand?
Name the steps in plain language, leave a note explaining why each non-obvious decision exists, and have a colleague make a small change to it while you watch. That last exercise is uncomfortable and it tells you precisely where the automation is opaque.
Should I build one large workflow or several small ones?
Several small ones, almost always. They are easier to test, easier to change, and when something fails you know which part. The exception is where the steps genuinely share state that would be awkward to pass between separate automations, and even then it is worth checking whether that state could live somewhere both could read.