How to build multi-app lead routing with Zapier

Recommendation (short)
Use one Zap that deduplicates first, then routes (CRM -> Sheet -> Slack). Deduplication should be handled by Storage by Zapier (fast, atomic) or a CRM “Find or Create” action. Add an error/path branch that notifies ops and retries failed items.

Concrete trigger/action pattern
1) Trigger: Google Forms — New Form Response (or New Spreadsheet Row if you prefer working with the response sheet).
2) Action: Formatter — Normalize key fields (trim/case-normalize email/phone). Use Formatter->Utilities to build a unique key: e.g., email || '|' || phone || '|' || timestamp-date.
3) Action: Storage by Zapier — Get Value using the unique key. If value exists, branch to Update flow (or Stop). If not, continue.
4) Action: CRM — Find Record by email/phone. Use “Find or Create” (or Find then Create) so the CRM enforces canonical dedupe and returns record id.
5) Action: Google Sheets — Add Row (or Update Row with the CRM id). Use the response timestamp as a reference. If you prefer a central data store, use Airtable with unique-record constraints instead.
6) Action: Slack — Post message to channel (include CRM link & lead id). Use Slack message attachments/blocks for clarity.
7) Action: Storage by Zapier — Set Value for the unique key (value = CRM id + timestamp) so future identical leads are blocked/updated.

Error handling and reliability for 500+ leads/month
- Use “Find or Create” actions where possible so apps dedupe themselves. Storage by Zapier avoids race conditions vs doing sheet lookups.
- Add a path for failures: on any step error, create a “Failed Lead” row in a separate Google Sheet and send an Ops Slack DM with the raw payload. This gives a manual retry queue.
- Enable Zapier’s built-in retry logic and set task history alerts for any spike in failures.
- For occasional bursts, consider Zapier’s Task Limits and rate limits—if you expect >1,000/mo or bursts, move dedupe/storage to a real DB (Airtable or small hosted Redis/Postgres) to avoid throttling.

Decision criteria
- Use Storage by Zapier if you want simplicity, speed, and 500–2,000 leads/month reliability.
- Use Google Sheets only if you need a human-readable log and no strong concurrency. Avoid Sheets-only dedupe because of race conditions.
- Use a DB (Airtable/Postgres) if you need strict unique constraints, higher throughput, or multi-user updates.

Best-for / Avoid-if
- Best-for: teams needing quick, maintainable routing without heavy infra; low to medium volume (up to a few thousand leads/mo).
- Avoid-if: you need atomic multi-step transactions or expect large bursts (use DB + webhook queuing instead).

Practical checklist before go-live
- [ ] Pick a unique key (email+phone or email+date).
- [ ] Normalize fields with Formatter.
- [ ] Implement Storage by Zapier get/set for dedupe.
- [ ] Use CRM Find/Create for canonical dedupe.
- [ ] Add “Failed Lead” logging sheet and Slack ops alerts.
- [ ] Test with duplicates, missing fields, and slow API responses.
- [ ] Monitor Zap History and set alert thresholds.

Optional enrichment: add a short ChatGPT step to classify intent/lead quality before routing (useful if routing depends on intent).
If you want, I can sketch the exact Zap configuration (field mappings and sample Formatter expressions).

Compare Zapier and Make