For four lessons you have been preparing: the task was picked, the process written, the fields defined, the tool chosen. In this lesson you build the first flow. The lesson covers the build order rather than the menus of a tool, so it works with whichever tool you chose.
For four lessons you have been preparing: you picked the task, wrote its process, defined its fields and chose its tool. In this lesson you build the first flow. The five parts introduced in the first lesson turn into practice here.
The lesson does not walk through the menus of a particular tool. What it covers is the build order: what to build first, what to test at each step, through which gate to go live. That order works with whichever tool you chose, because the five parts are the same five parts in every tool.
Prerequisites: the process map from lesson two, the field dictionary from lesson three and the tool you chose in lesson four. Without all three, the build rests on guesswork.
The build takes over the written rule. It does not take over the decision, the judgement or how an exception gets resolved; those are already written on the map and the build only repeats what is written.
This distinction turns into a concrete question during the build: if you have to think what should happen here while building a step, that step is missing from the map. Leaving the tool and going back to the map comes cheaper than producing a decision inside the tool.
Watching the trigger, running the steps in order, measuring the condition, carrying the data and marking the exception. All of them jobs written on the map.
Unwritten decisions, forks with a vague measure and the places where it depends gets said. Once those enter the build the tool produces a guess, and a guess can be quietly wrong.
Every moment you look at the map while building and cannot find the answer is a boundary sign. At that moment the build stops, the map gets updated, and then the build carries on.
The setup sheet is the single page record you fill in before building the flow. It takes the five parts from the process map and translates them into the language of the tool; while building you look at this sheet rather than at the screen.
The event that starts the flow and the channel bringing it. A form submission, an incoming message, a time, a record changing status. One clear beginning gets written.
The work to run in order, each with its output. The numbers from the map are kept; in the build they are called by the same numbers.
The forks and the measure of each fork. The measure gets written with the field name rather than an interpretation, then translated into an expression the tool has a counterpart for.
The systems to connect, in which direction data travels and which field corresponds to which field. The field matching gets written out one by one here.
What happens when the expected way does not run: where the record waits, who gets told, how the work is taken over by hand. This is the most skipped part of a build.
You do not enter the tool before the sheet is filled. A filled sheet tells you what you are building rather than which screen to open; when the two get mixed, the build follows the order the tool suggests and the map falls behind.
Start the build from the trigger and build only that first. Without adding a single step behind it, see that the trigger genuinely fires: does the flow wake when the event arrives, does the data it carries hold what you expect.
This first test carries the rest of the build. When the trigger is built wrong, every later step runs on wrong data and the error shows at the very end; looked at on its own here, it becomes clear in a minute.
The last two items are the source of two later silent faults: duplicate records and an unrecognised channel. Looked at during the trigger stage, both are cheap.
Rather than building all the steps and trying them at the end, add one step and test that step. Then one more. This pace looks slow, yet when a fault appears you do not have to hunt for which step produced it.
The question after each step is the same: is the output of this step the output written on the map? If it differs, stop there. When differences gather, the result showing at the last step turns into a mixture whose origin is unclear.
Every step added gets tested on its own. Moving to the next step without testing lets errors gather and makes the diagnosis dearer.
Is the record, message or field update the step produced the same as the output on the map. If not, the map gets questioned as much as the step.
The step number from the map gets used in the build too. A step called by the same number shortens both the conversation in the team and the later diagnosis.
Conditions are where the flow branches and the part most often simplified during a build. A condition written on the map as it goes to the agent of the district becomes an expression in the tool saying which field equals which value. The measure should survive that translation.
Build both ways at every condition. Building only the expected way and leaving the other empty leads to the record falling on that way stopping quietly. A way left empty gets tied to the exception.
An integration is connecting two systems so that they exchange data, and it is where errors gather during a build. The cause is usually not the connection itself but the field matching: a field called phone on one side can be called contact on the other.
Do the matching by writing it into the sheet rather than by dragging on a screen. A written matching both speeds the build up and tells you where to look later when a field name changes.
The last item is the door to the silent fault from a later lesson. When the returning response goes unread, the record did not go through yet the flow looks finished successfully.
The exception path is the most postponed and dearest part of a build. The reason for postponing it is simple: once the normal flow runs, the build looks finished. Yet a flow counted as finished stops quietly at the first different case.
The exception path does three things: it does not lose the record, it tells someone, and it makes room for the work to be taken over by hand. All three are written on the map; the build only places them into the flow.
Testing is not a separate stage of the build but a part of every step. As steps get added they get tested, and the next one does not begin before the test. This pace looks like it lengthens the build, yet it shortens the diagnosis time.
Do the testing with test data. Testing with a live customer record can lead to a wrong message reaching a real customer in case of an error. A test record wants a recognisable name and wants to be cleanable afterwards.
Going live is not opening the flow and waiting. A narrow gate means the flow first running on a limited input: what arrives through one channel, one district, the records of one employee. That way, when something goes wrong, the number of records touched stays limited.
A flow that passed through the narrow gate gets widened after a few days of watching. The widening happens the same way: one more channel, one more district. At every widening the same tests get repeated.
In the first week the flow runs, though under watch. Watching means going over the records the flow produces by eye once a day. This is not distrust but measurement: how does what you built in this lesson behave against the baseline you recorded in the first one.
The manual fallback also stays open through the first week. So that the work does not stop when the flow stops, the team wants to be able to do the same work by hand. Once the fallback is removed the flow becomes the only way; that decision comes after the measurement.
The real estate office had been preparing for four lessons: enquiry recording was picked as the pilot, the process map came out, the fields were defined and the no-code tool was chosen. Now it builds.
Setup sheet: trigger, a new enquiry landing from the portal. Steps: open the record, assign it to the agent by district, send the customer an acknowledgement, remind the next day if no reply went out. Condition: the district match. Integrations: portal, portfolio system, messaging. Exception: if the district does not match, the record waits in the office pool and the manager is told.
Trigger: the office sends a real test enquiry from the portal. The flow wakes. The incoming fields get compared with the field dictionary; the field the portal calls contact turns out to be phone in the dictionary, and the matching goes into the sheet.
Steps: only the step opening the record gets built first and tested. The output matches the output on the map. Then the assignment step is added and tested again. The acknowledgement step is left for last, because its output reaches the customer.
Condition: while building the district match a capitalisation difference appears: the portal sends KADIKOY while the portfolio system holds Kadikoy. The comparison is made insensitive to capitals and this goes into the sheet.
Integration: at the step writing to the portfolio system a mandatory field stays empty and the other side refuses. Because the returning response went unread, the flow had looked successful on the first try; it gets corrected so the response is read.
Exception: a test enquiry whose district does not match gets sent. The record waits in the office pool, a message goes to the manager and the message names the record. The manual takeover is tried and the record can be opened.
Narrow gate: the flow opens only on enquiries arriving from one portal. The other channels carry on by hand. The records arriving on the first day get gone over one by one.
First week: the records falling to the exception get counted, and most turn out to come from the phone field left empty on the portal. A requirement gets added on the form side. At the end of the week the reply time is compared with the baseline and the manual fallback is kept open.
The return of this lesson comes from genuinely building your pilot task. Start by downloading the setup sheet at the foot of the page and filling it in.
Every answer you cannot find on the map during the build is a place to go back to the second lesson and update the map. Producing a decision inside the tool means writing that decision somewhere nobody can see it.
Download the setup sheet (xlsx) · a single page sheet that has you fill in the five parts; the go live and first week sections are in it too.
The tool screen imposes its own order and the build comes loose from the map. The sheet is the one document telling you what to look at while building.
When a fault appears, which step produced it stays unclear. The one step, one test pace looks like it lengthens the build, yet it shortens the diagnosis.
In case of an error a wrong message can reach a real customer. A test record wants a recognisable name and wants cleaning once the testing is over.
The record falling on the unexpected way stops quietly. Both ways get built at every condition, and a way is left for the record matching none.
When the other side refuses, the flow looks finished successfully. The record did not go through and nobody notices.
The first week is a measurement week. Once the fallback is removed the flow becomes the only way; that decision comes after the measurement.
Before the flow goes live, you want to be able to say yes to every item below.
The terms that come up in build conversations. Speaking the same language as whoever builds the tool shortens the build.
In this lesson you built the first flow, passed it through the narrow gate and completed the first week under watch. The lessons ahead deal with the flow growing: connecting systems to one another, handling exceptions, bringing the team into the process and measuring the result.
If you would like to carry on with the published lessons, the module covering where to look when a flow does not run as expected is next.
Silent faults, the fault sheet, the halving method and lasting fixes.
The seven criteria score. Which tool this build uses gets decided there.
The whole training section and the modules added since.
If you would like to do the first build together, write to us and we can fill the sheet in with you.
Get a Quote on WhatsApp