Your goal
Build an explicit n8n branching workflow and test every route.
PROJECT LAB / MODULE 07
BorrowBox dispatcher: a reliable automation
Route a messy lending request into the right queue without asking an AI.
The situation
A fictional lending desk receives normal requests, urgent requests and records without an item ID. Missing fields go to needs-details, urgent valid requests go to priority, and other valid requests go to normal.
A first win
Predict the queue for one sample request by hand.
Keep this artifact
A workflow export and a six-case input/output table.
Explore the mechanism
This interactive model teaches the mechanism. It does not call a model, search your files or send messages.
Why this works
Rules can be enough
A known routing policy is easier to inspect as explicit conditions. An LLM would introduce variability without adding a needed capability to this task.
Validate before routing
Missing item IDs and strings pretending to be booleans can produce incorrect branches. Check shape and type before making the routing decision.
Retries need identities
If a trigger repeats a request, a stable request ID lets you recognize duplication. Otherwise a reliable retry can accidentally create two jobs.
Build it, step by step
Write the routing table
Open dispatcher-cases.json. For each record predict needs-details, priority or normal. Define what counts as a valid item ID and urgent boolean.
Check: Each input has one expected outcome.
Need a hint?
Missing details take precedence over urgency.
Build the trigger and fields
In your n8n test workflow use Manual Trigger and Edit Fields to supply the sample record. Keep requestId, itemId and urgent as typed fields.
Check: The output matches your input schema.
Need a hint?
Do not use a real production webhook for this first test.
Branch for missing details
Add an If node for missing or empty itemId. Route true to a named needs-details output.
Check: An urgent request with no item ID still asks for details.
Need a hint?
This branch must happen before the urgency branch.
Branch for urgency
On valid requests add an If node that compares urgent as a boolean. Set the route field using Edit Fields on each branch.
Check: Valid urgent and normal requests reach their expected queues.
Need a hint?
The string "false" is different from boolean false.
Run every fixture
Execute each of the six cases. Record actual output and execution ID beside the expected route.
Check: All outputs match the table or have a documented type-validation error.
Need a hint?
Do not declare success from a single green execution.
Explain reliability
Export the workflow with no credentials. Describe how you would reject duplicate request IDs and handle an execution failure before enabling a real trigger.
Check: A partner can trace every branch.
Need a hint?
Deduplication is an extension until an actual store is connected.
Build with a clear contract
Design an n8n test workflow with Manual Trigger, Edit Fields and If nodes. Input fields: requestId string, itemId nonempty string, urgent boolean. Missing itemId routes to needs-details; valid urgent routes to priority; valid nonurgent routes to normal. Give a decision table including missing data, true, false, string "false" and repeated requestId. Explain where type validation and deduplication belong. Do not claim a dedup store exists until it is connected.
When it goes sideways
Missing item goes to priority
Urgency ran before validation.
Try: Reorder the workflow so missing details stop the normal routing path.
The string false behaves strangely
Input values were not typed consistently.
Try: Validate booleans instead of relying on truthiness.
Duplicate requests create duplicate work
No stable request identity is checked.
Try: Add a request-ID store before acting on real requests.
Review your evidence
Tick a criterion only after checking your own artifact. These are self-reported checks, not an automated certification.
Make it your own
Add a quiet-hours policy
Introduce a time window: valid urgent requests during quiet hours should wait for review. Write boundary tests before editing the workflow.
- Start/end time boundaries are tested.
- Missing details still take precedence.
- The decision table and workflow agree.
Check the mental model
Why use fixed conditions here?
Which branch runs first?
Remember the distinction
Rules can be enough
A known routing policy is easier to inspect as explicit conditions. An LLM would introduce variability without adding a needed capability to this task.
Validate before routing
Missing item IDs and strings pretending to be booleans can produce incorrect branches. Check shape and type before making the routing decision.
Retries need identities
If a trigger repeats a request, a stable request ID lets you recognize duplication. Otherwise a reliable retry can accidentally create two jobs.
Go to the source
MODULE 07
n8n: Edit Fields
Use the primary documentation to verify this part of your build.
Apply it in the project labMODULE 07
n8n: If node
Use the primary documentation to verify this part of your build.
Apply it in the project lab