Question 1

Walk me through how you build a simple workflow.

Accepted Answer

Narrate the sequence and add why at each step — that is what shows experience. "First I choose the trigger: Schedule if the event is time-based, Webhook if an external system notifies us, or the service's own trigger node if it has one. Then I add one node and run it immediately to look at its output — because without knowing the real data shape I cannot write the next step's expressions correctly. Once data is flowing I shape it — drop the fields I do not need with Edit Fields and name the ones I do. Skipping that step makes every later node unreadable. The sending node comes last, and I point it at myself first. When everything works I switch to the real recipient and publish the workflow."

Question 2

A workflow is not producing the result you expect. What are your first three steps?

Accepted Answer

Show a sequence — a vague "I'd check things" answer sounds weak. 1. Open the execution history and select the failed run. You see which node it stopped at, which narrows the search immediately. 2. Look at that node's INPUT data, not its output. Most failures are not in the node itself but in the unexpected shape of the data reaching it — a missing field, an array, a null. 3. Re-run the node against pinned data. That lets you iterate on the problem part repeatedly without calling the real API again. "Those three steps localise the problem to either the incoming data or the node's configuration. Everything after that is a concrete fix."

Question 3

Why do you run nodes one at a time instead of all at once?

Accepted Answer

The question looks simple but probes your working method. "Two reasons. First, the real data shape often differs from the documentation — a field is named differently, or an object arrives where you expected an array. You only learn that by looking at the output. Second, localising failure. Running a ten-node workflow at once and concluding 'something is wrong' tells you nothing; when you see what the data becomes at each step, a mistake shows up the moment it appears. On top of that comes pinned data: I capture one real response, pin it, and then iterate on the downstream nodes against that fixed data — no burning through API limits and no waiting on each run."

Step	What to do	Watch out for
1. Add the trigger	Schedule Trigger → pick an interval (every day at 09:00, say)	Check the instance timezone — the schedule is computed against it
2. Fetch the data	HTTP Request → method GET, enter the URL, then run just that node	Always inspect the output — you cannot build the next step without knowing the field names
3. Shape the data	Edit Fields (Set) → create a field, fill the value with an expression	Drag and drop from the left panel instead of typing the field by hand
4. Send it	Add a Telegram / Slack / Gmail node and create the credential	Send to yourself first — not to a real recipient while testing
5. Publish	Save and publish (activate) the workflow	An unpublished workflow does not listen to its trigger

Your first workflow: from source to notification

📚 Sources and documentation