Route a fictional request to review or the normal queue.
Build one thingCheck it worksChoose an extension
Module 07 / Build together
Before you start.
01
You already know
A facilitator-prepared n8n instance. No AI model needed.
02
Open these tools
n8n workflow editor with permission to create test workflows.
03
Check the requirement
Hosting/cloud terms vary. Use a prepared workshop instance; no paid model call.
Module 07 / Build together
Your first small win.
Sketch a tiny workflow: manually start, create a fictional request with urgent=true, send urgent requests to review and others to the normal queue. Name the inputs and the expected output. Do not add AI or external messages.
Module 07 / Build together
What happens between input and output?
1A trigger starts the workflow.
2Fields carry the data between steps.
3An If node follows a rule you can explain.
Module 07 / Build together
Step 01. Create a test workflow.
1Start a new workflow named request-router.
2Add Manual Trigger.
3Execute it and inspect the output panel.
Module 07 / Build together
Step 02. Add a fictional request.
1Connect Edit Fields (Set).
2Set request to Room booking and urgent to Boolean true.
3Run this node and check both values.
Module 07 / Build together
Step 03. Add the rule.
1Connect an If node after Edit Fields.
2Use the Boolean value {{$json.urgent}}.
3Set the condition to is true.
Module 07 / Build together
Step 04. Name both outputs.
1On true, add Edit Fields with route=review.
2On false, add Edit Fields with route=normal.
3Keep the request field in each output.
Module 07 / Build together
Step 05. Test both branches.
1Run with urgent=true and expect review.
2Change urgent to false and expect normal.
3Use Boolean values, not the text true or false.
Module 07 / Build together
Step 06. Save the working version.
1Name the nodes clearly.
2Save the workflow and export its JSON if permitted.
3Keep it manual; there is nothing to publish yet.
Module 07 / Build together
Make the working version.
Write a manual test table for my request router. It uses a Boolean urgent field: true means review, false means normal. Include a missing-field case and a wrong-type case. Do not claim the workflow was executed.
Module 07 / Build together
Ask for a review. Then check it.
Check my workflow design for missing fields, text-versus-Boolean mistakes and dropped request data. Give one correction at a time. Design: Manual Trigger -> Edit Fields -> If -> review or normal Edit Fields.
Module 07 / Build together
Prove your result works.
1True reaches review; false reaches normal.
2Request text survives routing.
3Wrong types and missing fields are handled deliberately.
Module 07 / Build together
When it does not work yet.
01
Always the same branch
Inspect the field type and If expression.
02
Request disappeared
Keep input fields or map them again in Edit Fields.
Module 07 / Build together
Choose your next challenge.
01
Core complete
Show one checked output to a partner.
02
Extension 1
Add a third priority without using AI.
03
Extension 2
Import another request and test the rule on it.
Module 07 / Build together
Keep the result. Keep the evidence.
Route a fictional request to review or the normal queue.
Save your filesSave your promptName the next change
Module 07 / Build together
Sources you can check.
01
n8n
Edit Fields
02
n8n
If node
Automate one clear decision.
3 minutes
Outcome: Route a fictional request to review or the normal queue. This is a 60-minute in-person laptop session after preflight. No setup-duration guarantee. Core first, extensions second.
References
Before you start.
3 minutes
Hosting/cloud terms vary. Use a prepared workshop instance; no paid model call. The facilitator verifies accounts, installed tools and model/host connections before the session. Pair up if setup is incomplete. Do not create accounts or incur costs without understanding the provider terms.
References
Your first small win.
5 minutes
Quick win: Run a Manual Trigger and see one data item. Aim for a visible result in the first 15 minutes after preflight. Explain that generated code/output is untested until the learner checks it. If tools are unavailable, inspect the prepared example with a partner.
References
What happens between input and output?
3 minutes
Ask a learner to explain each stage in their own words. This is a teaching model, not a promise that all tools behave identically.
References
Step 01. Create a test workflow.
3 minutes
Perform these numbered actions on the laptop. Pause after the step and inspect the result. Use fictional or approved material.
Use fictional practice inputs. Ask learners to show their work, not just the final answer.
References
Ask for a review. Then check it.
4 minutes
Use fictional practice inputs. Ask learners to show their work, not just the final answer.
References
Prove your result works.
6 minutes
These are manual acceptance tests for the learner to perform. No test is claimed to have run merely because it appears here. Ask pairs to demonstrate one pass and one corrected failure.
References
When it does not work yet.
4 minutes
Choose the observed symptom. Change one thing and rerun the smallest test. Avoid restarting the whole project or adding tools before diagnosing the current step.
References
Choose your next challenge.
5 minutes
Experienced learners use the extensions while beginners complete the same core outcome. An extension is optional, not a prerequisite for participating.
References
Keep the result. Keep the evidence.
3 minutes
Save the working version before leaving. Add a short note: what worked, what needed correction and what you would try next. The next module builds on the saved output.
References
Sources you can check.
2 minutes
Primary sources checked during course creation on 2026-10-08. Provider interfaces and availability can change. The examples, prompts and activities are original community teaching designs. Source links explain capabilities; they do not prove these fictional exercises were executed.
