A lead-intake workflow should be tested for failure paths before it is connected to outreach or a CRM. Here is a small review-first test matrix that can be used with pinned data or manual executions.
Suggested workflow shape
Trigger → Normalize fields → Validate → Check duplicate → Route
Keep the workflow inactive while testing. Do not let the test branch send emails, SMS, or WhatsApp messages.
Five useful test cases
-
Valid lead
- Required fields are present.
- Consent state is acceptable for the intended action.
- No matching record exists.
- Expected result: create a review task or CRM record.
-
Missing contact data
- Remove the email and phone values.
- Expected result: route to a validation-error branch with a clear reason such as
missing_contact_method.
-
Missing or invalid consent
- Use an empty, false, or unknown consent value.
- Expected result: do not create an outreach task. Send the item to human review.
-
Duplicate lead
- Run the same normalized email, phone, or source ID twice.
- Expected result: update or flag the existing record instead of creating a second one.
- Normalize before comparing: lowercase email, trim spaces, and standardize phone digits.
-
CRM/API failure
- Simulate a timeout, 429, or 500 response.
- Expected result: retain the input, record the error, and place the item in a retry or review queue. A partial write should not silently continue as success.
Practical n8n setup
Use an Edit Fields (Set) node to create synthetic fixtures, an If or Switch node for explicit validation routes, and a stable idempotency key such as:
source + ":" + normalized_email
Store a compact outcome for every test:
- fixture ID
- route taken
- reason code
- timestamp
- downstream write status
The important rule is that failed validation should be an expected workflow outcome, not an unhandled execution error. Human approval can then happen before any customer-facing action.
What other failure path has caused problems in your lead workflows?