Treat no matching records as its own business outcome only after confirming that the lookup had valid inputs and completed successfully. Missing input, a legitimate empty result and an upstream failure require different decisions.
Define what zero actually means
A valid search can legitimately find nothing. That might mean there is no work today, an expected item is absent, or a new record may be considered. The correct interpretation depends on the process.
n8n documentation establishes connected workflows and execution-history context. It does not establish how every connected service represents empty responses or failures. Verify those details during implementation rather than assuming a universal output shape.
The editorial contract below concerns business meaning, not any particular node's behaviour.
Write a no-result decision table as rules
Use these text-based rows in your review worksheet:
- Valid input + confirmed successful lookup + zero matches: apply the agreed normal-empty policy.
- Required input absent: classify as input exception; do not describe it as “not found.”
- Lookup completion unconfirmed: classify as unknown outcome and investigate.
- Explicit upstream failure: use the failure route, not the normal-empty route.
- One valid match: continue with the matched record.
- Multiple matches where one is expected: hold for ambiguity review.
For every row, record an owner, permitted next action and completion evidence. If normal emptiness should end the process quietly, still define how the business can distinguish “nothing to do” from “never ran.”
Evaluate a hypothetical reconciliation lookup
A fictional Nagpur office checks whether synthetic purchase request PR-330 has a corresponding internal instruction.
Case A supplies PR-330, the lookup is confirmed successful, and zero matches return. Under its illustrative policy, this becomes “instruction missing; investigate eligibility,” not automatic creation.
Case B omits the request reference. It becomes an input exception even if the returned list appears empty.
Case C supplies PR-330 but the lookup times out. The result remains unknown.
Case D finds two matching instructions. It becomes a possible duplication case, not permission to choose the first.
Evaluate the design by asking whether any case could accidentally create another instruction. Only a separately authorised creation policy should permit that action. These cases are synthetic, not hands-on results.
Stop when absence cannot be proved
Stop consequential downstream actions when successful lookup completion cannot be established. Next, confirm the input, lookup outcome and expected match count before deciding what absence means.
When comparing access offers, check the automation catalog for access format and saved terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence or lookup reliability.
Sources and scope
Source material checked 29 October 2026; features/policies may change. n8n workflow documentation establishes the workflow model and execution context. The no-result rules and reconciliation examples are editorial process advice, not universal platform response semantics.