Lead inquiry to CRM and team notification: an n8n demonstration

Sample project using fictional data, not a client case study. External services are simulated.

Five fictional inquiries enter this example. Two become contact records, one is recognised as a duplicate, and two are rejected because required details are invalid. A simulated notification failure leaves the second contact available in the result.

This is a small n8n demonstration of the decisions between receiving an inquiry and notifying a team. Its CRM is an in-memory stand-in, and its notifications are local records. It does not write to a real CRM or send a message.

Start with a small, inspectable input

The manual workflow receives a fixture containing a name, email and brief for each inquiry. One email appears twice with different casing and surrounding spaces. Another inquiry has an invalid email; another is missing a name.

The first step trims the fields and lowercases the email before checking required values and length limits. Invalid entries receive a rejected result and do not create a contact.

Decide what counts as a duplicate

For this demonstration, a normalized email identifies a contact within a single execution. The first valid inquiry creates a record. A later inquiry with the same normalized email receives a duplicate result without overwriting the original record.

That is a sample policy, not a rule for every business. The same person may legitimately submit multiple projects. Before connecting a CRM, decide whether a new inquiry should update a contact, create a separate opportunity, or be treated as a retry of an existing submission.

Save before notifying

The sample creates its contact before attempting the notification step. One fixture deliberately makes that step fail. The result records a notification failure while retaining the contact.

This separation matters because contact creation and team notification are different outcomes. A production workflow should make those outcomes visible independently and define how to retry a failed notification without recreating the contact.

What the test proves

The workflow imported and ran in an isolated local n8n instance. Its exported code also passed tests for validation, duplicate handling and retained contacts after a simulated notification failure.

The contact store resets on every run. It offers no persistent deduplication, concurrency protection or external CRM integration. Those require a real storage boundary and tests against the chosen service.

Try the sample

Import the inactive lead-intake workflow into a local n8n workspace and execute it manually. Download: lead-intake workflow export (JSON, about 3.4 KB). It contains only a manual trigger and code steps, so the CRM and notifications stay local stand-ins. Inspect the final JSON for contacts, rejected inputs, duplicates and notification results. All fixture emails use example.test, and no credentials are needed.

If you need an inquiry workflow connected to your actual tools, see automation services or send a short project brief describing the source, CRM and team notification destination.