The Workflow That Sent the Right Message to the Wrong Person: Row-to-Recipient Mapping in n8n

Description and use

In an n8n workflow, messages were sent to wrong recipients due to silent mapping errors. Implemented key‑based mapping, unique key enforcement, freshness checks, and a send‑step assertion to prevent mis‑sent messages.

Problem

Messages were sent to incorrect recipients because row‑to‑recipient mapping failed silently.

Outcome

The workflow now prevents mis‑sent messages by enforcing key integrity, handling ambiguous lookups, and validating recipients at send time, reducing post‑send corrections.

Workflow

• 1. Retrieve rows with business keys (lead id, customer id).
• 2. Enrich rows via lookups ensuring unique keys or fail on ambiguity.
• 3. Apply filtering/joins while preserving business keys.
• 4. Cache enrichment with freshness rules; re‑fetch or halt if stale.
• 5. In send node, resolve recipient from key independently and assert match with row’s key.
• 6. If assertion fails, halt run and create review item with both values.
• 7. If all assertions pass, send message to resolved recipient.

Evidence

The scariest workflow failure I have seen did not throw an error, did not page anyone, and did not show up in any success metric.

Source

The bug was never in the send step. It was in the mapping step, one or two nodes earlier, where a row and a recipient stopped belonging to each other.

Source

Before sending, assert that the recipient on the message matches the business key on the row, using an independent source.

Source