n8n + Notion: How to Build a Full CRM Automation for Free

The entry point of the whole system. Whenever a new lead comes in from any source, n8n creates a contact row in the Notion database automatically. The workflow doesn't care where the lead came from — you use a Webhook trigger node as the universal receiver and configure each form to POST to that URL, or use native n8n nodes for Typeform and Calendly.

The first node after the webhook is a deduplication check. The Notion node with "Query Database" action filters the Contacts database by the email property: filter: { property: "Email", email: { equals: "{{ $json.email }}" } }. If the query returns a result, the contact already exists — the IF node branches to an "Update existing" path rather than creating a duplicate. Without this check, every second form submission from the same person creates a new row, and your CRM becomes noise within a week.

The "Create new" path uses the Notion "Create Page" action with the database ID of your Contacts database. Map the form fields to the Notion properties: Name → title, Email → email property, Source → select property (the value must exactly match one of your Select options — case-sensitive). Set Status to "New" as the default. The page ID returned from this step is what downstream workflows use to link deals and update fields.

Your lead submitted a form with their name, email, and maybe a message. You now need to know: what does their company do, how big is it, are they a good fit? Without enrichment, your rep has to research this manually before making contact — typically 5–10 minutes per lead that adds up fast. This workflow does it automatically in the 30 seconds between submission and the rep seeing the Slack notification.

The workflow can run in two modes depending on your budget. Free mode: Use an HTTP Request node to call the Clearbit Discovery API or Hunter.io's domain search endpoint — both have free tiers (100 requests/month on Clearbit, 25/month on Hunter). Pass the email domain (everything after the @) as the query parameter. The response includes company name, industry, employee count, LinkedIn URL, and approximate revenue. Paid mode: Apollo.io ($49/month) or RocketReach ($80/month) return much richer data including direct phone numbers and technology stack.

After the enrichment call, the Notion Update Page action writes the data back to the contact: Company field gets the company name, the Notes field gets appended with "Enriched: [industry], [size] employees, [HQ location]". The rep opens the Notion contact and the research is already there. For leads where enrichment fails (personal Gmail addresses, etc.), the IF node routes to an empty branch — no error, the contact just stays without company data.

For teams with more than one sales rep, lead assignment is either manual (a manager looks at the queue and drags leads to reps), or it doesn't happen consistently. This workflow removes that step entirely. The assignment logic lives in a Google Sheet — a simple table mapping source or industry to a rep's name and Notion user ID. When a new lead comes in, n8n reads the table, finds the matching rep, and sets the Assigned To property in Notion. The Slack notification goes directly to that rep with the lead's details and a direct link to the Notion contact page.

The Google Sheet assignment table has three columns: Source (matching your Notion Source select options), Rep Name, and Notion User ID. The Notion User ID is found in your workspace's People settings — it's a UUID that the Notion API requires for the Person property type. Round-robin assignment (ignoring source) is handled by a Code node that tracks the last assigned rep in a single Sheets cell and rotates through the list on each execution.

The Slack message is where the context matters. It should include: the lead's name, email, company (from enrichment), their form message verbatim, which source they came from, and a direct URL to the Notion page — formatted as https://notion.so/{page_id_without_hyphens}. With this, the rep goes directly from Slack notification to the contact record without searching. Response time drops from hours to minutes.

This is the workflow that prevents leads from going cold silently. Without it, a rep contacts a prospect, gets busy with other deals, and doesn't follow up for 10 days. The prospect moves on. With it, if a contact's Next Follow-up date is today (or earlier) and their Status is still Contacted or Qualified, the rep gets a Slack reminder with the contact name, when they were last contacted, and a link to the Notion page.

The Schedule Trigger fires every weekday at 9 AM. The Notion "Query Database" action pulls all contacts where the Next Follow-up date property is on or before today AND the Status is not Won or Lost — using Notion's filter API: { "and": [ { "property": "Next Follow-up", "date": { "on_or_before": "{{ $now.toISO() }}" } }, { "property": "Status", "select": { "does_not_equal": "Won" } }, { "property": "Status", "select": { "does_not_equal": "Lost" } } ] }. The query can return multiple contacts — the SplitInBatches node processes each one individually and sends a separate Slack message to the assigned rep.

One important detail: after the rep takes action and updates Last Contact in Notion, they should also set the Next Follow-up date to the next planned touchpoint. This keeps the system accurate. You can add a Notion Trigger workflow that fires when Last Contact is updated and automatically sets Next Follow-up to 3 business days later — removing even that manual step.

When a deal moves through your pipeline — from Demo to Proposal, from Proposal to Negotiation — two things should happen automatically: the event gets logged in a shared tracking sheet (so you have pipeline history and can review why deals progressed or stalled), and the relevant team members get notified in Slack with the deal name, value, new stage, and owner. Without automation, both steps are manual, which means neither happens consistently.

This workflow uses the Notion Trigger node set to watch the Deals database for page updates. The trigger fires on any property change, so the first step is a Code node that checks whether the Stage property actually changed — comparing the current value to the previous value stored in a Google Sheets log row. If Stage didn't change (maybe the rep updated a note), the workflow exits. If Stage changed, the new stage and timestamp get written to the log row, and the Slack node posts to the #sales channel with the deal details.

The Slack message format matters here: "Acme Corp — Enterprise Plan moved to Negotiation ($8,400 · owner: Sarah). View deal →". This gives the whole team pipeline visibility without anyone needing to check Notion. Managers get an accurate read of pipeline health from their Slack feed alone.

Closing a deal is the moment where the process often breaks: the sales rep marks it won, celebrates briefly, and then the handoff to the next stage — whether that's customer success, onboarding, or invoicing — happens inconsistently. Some customers get a welcome email within the hour. Others don't hear anything for two days. This workflow ensures the handoff is instant and identical every time.

The Notion Trigger detects when a deal's Stage changes to "Won". The workflow then runs a sequence of three parallel branches: (1) Send a welcome email to the contact via Gmail or SendGrid — the template pulls the contact's name and the deal name from the Notion pages linked via the Contact relation; (2) Post a #wins message to Slack with the deal name, value, owner, and a confetti emoji — these messages are genuinely good for team morale and worth the 30 seconds of configuration; (3) Update the contact's Status from "Qualified" to "Won" in the Contacts database, and move the contact to a "Customers" filtered view by updating a separate Customer boolean property.

The "Lost" branch follows the same pattern but with a different email (honest, non-salesy close: "Thank you for considering us — the door is open if anything changes"), a Slack notification to the owner only (not the whole team), and a mandatory Lost Reason field update in the Deals database. Tracking loss reasons is where most small CRMs fail — they record that a deal was lost but not why, making it impossible to improve the process.