How to Prevent Duplicate Salesforce Leads and Contacts in Zapier

01Sarah Exists Three Times

A prospect named Sarah submits a demo request through the website. A Zap fires and creates a Salesforce Lead. Two weeks later, Sarah attends a webinar, and a second Zap, watching a different trigger, creates another Lead. A few days after that, she books a call through Calendly, and a third Zap creates a Contact, because whoever built that particular Zap assumed anyone booking a call must already be a known relationship.

Salesforce now has three records for one person. One sales rep emails the original Lead. A different rep calls the Contact. Marketing attributes the webinar and the demo request to what looks like two separate prospects, because as far as the reporting is concerned, they are two separate prospects. Sarah, meanwhile, gets the same outreach email twice from two different people at the same company within a week of each other, which is its own kind of bad first impression.

None of this happened because Salesforce is bad at deduplication. It happened because three separate Zaps each independently decided, with no shared logic and no awareness of each other, that the safest thing to do with new data was create a new record. This guide covers how to prevent duplicate Salesforce Leads and Contacts in Zapier: search-before-create logic, a real matching hierarchy, external IDs, safe handling of retries and repeat inquiries, and a human-review path for the genuinely ambiguous cases that no rule should try to auto-resolve.

02The Complete Architecture

A record arrives from wherever it originated. Before anything gets created in Salesforce, the incoming data gets normalized, so that formatting differences alone don't cause a real match to be missed. The workflow then checks whether this specific source event has already been processed, protecting against retries and replays. From there it searches Salesforce, Contacts first in most B2B data models, then Leads, then, where relevant, Accounts, and evaluates what it finds against a defined matching hierarchy. A confident match gets updated. No match at all results in a new record. Anything in between, a plausible-but-uncertain match, gets routed to a human reviewer rather than resolved automatically in either direction. Every decision, whichever branch it took, gets logged with a reason, so the whole system stays auditable.

The goal stated plainly, since it's easy to lose sight of once you're deep in matching logic: the goal is not to never create another record. New people show up in a growing business constantly, and a system that's too aggressive about matching will start silently merging distinct people into each other's history, which is arguably worse than the duplicate problem it was meant to solve. The actual goal is narrower and more achievable: make sure the system reliably knows when to create, when to update, and when to stop and ask a human, instead of guessing every time.

03Why Salesforce Duplicates Actually Happen

Duplicate records rarely trace back to one obvious cause. They accumulate from multiple lead sources feeding Salesforce independently, several Zaps each watching different triggers with no shared identity logic, manual entry by sales reps who don't check first, CSV imports run without deduplication, Web-to-Lead submissions alongside API-created records, form resubmissions from a genuinely interested prospect, Zap retries after a timeout, webhook events that fire more than once for the same underlying action, Lead conversion creating a Contact that a separate, unaware Zap doesn't know to check for, people changing email addresses or company domains, shared inboxes and household emails, inconsistent phone number formatting, and, underlying most of the above, the simple absence of any stable unique identifier tying an external event back to a specific Salesforce record.

The reason this list matters: duplicate prevention has to be solved across the entire intake architecture, not patched into a single Zap. Fixing one integration while four others keep creating records blindly just relocates where the duplicates come from.

04Define What Actually Counts as a Duplicate

Not every similar-looking pair of records is the same situation, and treating them identically causes real damage in both directions. An exact duplicate is the same person with the same email and the same company appearing twice. A probable duplicate is the same person with slightly different field values, a typo in the name, a formatted-differently phone number. A related record is a different person at the same company, which should never get merged just because the company matches. A repeat inquiry is the same person genuinely returning with a new request, which needs a new business event recorded, not a rejected duplicate and not a second person record. A Lead-and-Contact match is a prospect who existed as a Lead and has since become a Contact, commonly through conversion, an event that plenty of Zaps built before that conversion happened simply don't know to check for. Shared contact information is two distinct people using the same business phone number or a shared front-desk email, where matching on that shared field alone will confidently merge two different humans.

The practical implication: "same email equals duplicate" is a genuinely useful heuristic and a genuinely unsafe universal rule. It needs qualification by exactly which of these situations is actually in play.

05Decide Which System Controls Identity

Salesforce should be the CRM system of record. External sources, whatever generated the inquiry, are event sources feeding into it. Zapier is the integration layer connecting the two, and its job is to apply one consistent identity-matching policy, not to let ten different Zaps each invent their own version of what counts as a match. This sounds obvious stated plainly, and it's exactly the principle most duplicate-riddled Salesforce orgs violated gradually, one well-intentioned Zap at a time, without anyone deciding to.

06Define a Matching Hierarchy, in Priority Order

A workable matching hierarchy, in priority order, looks something like: an external system ID first, since it's the most deterministic signal available; a Salesforce record ID if the external system already stores one; a verified email address; a verified phone number; company domain combined with company name; name combined with company as a weaker fallback; and, below all of that, human review. Deterministic identifiers, an ID a system generated and reliably reuses, should always outrank fuzzy matching on human-entered fields like name or company, which vary in formatting, spelling, and completeness in ways an ID never does.

07Use Salesforce Record IDs Whenever They're Already Available

If an external system already stores a Salesforce Contact or Lead ID from a previous sync, use it directly rather than searching by email again on every subsequent interaction. A customer portal that already knows a person's Salesforce Contact ID should update that specific record by ID, full stop, rather than re-running an email search that reintroduces every risk covered in this guide for no reason. Searching by email is what you do when you don't yet have a stable ID; once you have one, use it.

08Use External IDs to Anchor Every Other Source

For sources that don't natively speak Salesforce IDs, a Salesforce External ID field storing that source's own identifier, a Meta Lead ID, a HubSpot Contact ID, a Shopify Customer ID, a Calendly Invitee ID, a Stripe Customer ID, an event-registration ID, an internal customer ID, gives you the same deterministic anchor. Once that external ID is stored on the Salesforce record, every future event from that same source can match against it directly instead of falling back to fuzzy field matching.

Beyond deduplication itself, external IDs are what make idempotency, reconciliation, and safe retries actually work, since Salesforce's own upsert capability is built around them: the REST API's upsert-by-external-ID endpoint looks up the record by that field's value and updates it if found or creates it if not, in a single call, based on the External ID field's value rather than the Salesforce record ID. Note that this specific upsert-by-external-ID behavior is a Salesforce API capability, not something Zapier necessarily exposes as a single action; confirm current Zapier Salesforce action support directly, since whether a given integration platform offers a true single-call upsert or requires you to build the find-then-branch logic yourself varies and changes over time.

09Normalize Email Addresses Before Comparing Anything

Lowercase the address, trim stray whitespace, and validate basic format before using an email for matching, so that "Jane@Example.com," " jane@example.com," and "JANE@EXAMPLE.COM" all resolve to the same comparison value. Be careful not to over-normalize legitimate addresses in the process. Plus-addressing, jane+demo@example.com versus jane@example.com, is a case worth deciding on deliberately rather than defaulting to stripping the +tag automatically; some businesses want those treated as the same person, others deliberately use plus-addressing to track which form generated an inquiry and don't want that signal destroyed by normalization.

10Normalize Phone Numbers Before Comparing Anything

Incoming phone numbers arrive as "(555) 123-4567," "5551234567," and "+1 555 123 4567" more or less interchangeably depending on the source, and all three need to normalize into one consistent format before comparison is meaningful. Account for country codes, extensions, and genuinely international numbers if the business operates outside a single country. Be conservative about matching on phone alone: shared business lines, front-desk numbers, and family landlines mean phone-only matching produces real false positives, distinct people who happen to share a phone number getting treated as the same person, so combine phone matching with at least one additional field rather than relying on it in isolation.

11Normalize Company and Domain Data

"Acme Inc.," "ACME," and "Acme, LLC" should normalize to a comparable value before being used for Account matching, and "acme.com" and "www.acme.com" should resolve to the same domain. Domain matching is genuinely useful for B2B Account lookup, but it carries real risk with consumer email domains, Gmail, Outlook, Yahoo, and similar, where the domain tells you nothing about which company someone works for. It also needs care around franchise locations that may share a parent domain but represent distinct operating entities, subsidiaries of a larger parent company, and agencies submitting inquiries on behalf of their own clients, none of which should get automatically collapsed into a single Account just because the domain matched.

12Search Salesforce Before Creating Anything, as a Fixed Rule

The basic pattern, trigger, search for a matching record, then update if found or create if not, needs to apply consistently across Leads, Contacts, Accounts, and, where relevant, Opportunities, not just to whichever object happened to be top of mind when a given Zap was originally built. Treat "search before create" as a non-negotiable rule for every business-critical intake workflow, not a nice-to-have added after duplicates start showing up.

13Search Contacts and Leads Separately, and Don't Skip Either

When a new person arrives, search Contacts by email first. If a Contact is found, update it and notify the existing owner rather than proceeding further. If no Contact is found, search Leads by the same email. If a Lead is found, update it. Only if neither search returns a match should a new Lead actually get created.

The failure this specifically guards against: a Zap that only ever searches Leads, never Contacts, will happily create a brand-new Lead for someone who converted to a Contact months ago, since as far as that Zap is concerned, the Lead object search came back empty and that's the whole story. This is one of the single most common causes of duplicate records in Salesforce orgs that already had some search-before-create logic in place; the logic existed, it just wasn't checking the right object.

14Decide the Search Order: Contacts First, or Leads First?

For most B2B businesses, Contacts should take precedence in the search order, since a Contact represents an already-established, generally already-qualified relationship, while a Lead represents an unqualified prospect earlier in the funnel. But this isn't universal, and it depends on your specific Salesforce data model and sales process; some organizations intentionally keep everyone as a Lead until a formal qualification step, in which case an existing Lead match might reasonably take precedence over a stale, long-inactive Contact. Define this explicitly as a written policy rather than letting whichever order a given Zap happens to check first become the de facto rule by accident.

15Check Existing Accounts Before Creating New Ones

For B2B lead flows, extract the company domain from the incoming email, search for a matching Account, and if one exists, attach the new Contact or Lead to it, or route the inquiry to that Account's owner, rather than letting a second Account for the same company get created. Duplicate Accounts tend to create more downstream damage than duplicate Leads or Contacts alone, since an Account is the anchor for Opportunities, related Contacts, activity history, and often billing or contract data; splitting that across two Account records fragments a genuinely important, load-bearing piece of CRM structure, not just a single person's record.

16Preserve Existing Ownership When a Match Is Found

When an existing Contact or Account turns up in the search, don't automatically overwrite the current owner with whatever generic round-robin or new-business assignment logic the workflow would otherwise apply. The pattern: use the existing Account or Contact owner, and notify that owner of the new inquiry, rather than reassigning. Running every new inquiry through fresh assignment logic regardless of existing relationships is exactly the kind of automation collision covered in our companion guide on automatically assigning Salesforce leads with Zapier, where existing-relationship ownership needs to explicitly outrank round robin in the routing priority order, not get silently overridden by it.

17Build Find-or-Create Logic in Zapier

Conceptually: trigger, run the incoming data through Formatter for normalization, search Salesforce, then branch through Paths into an Update action for a found record or a Create action for no match. Zapier's Salesforce "Find Record by Query" search action has, as of relatively recent updates, gained the ability to create a new record directly when no match is found, collapsing the separate find-then-branch-then-create pattern into a single search step for straightforward cases. Whether that specific create-if-not-found option is available and how it behaves for your object and search criteria is worth confirming directly in Zapier's current Salesforce app documentation before relying on it, since integration platform capabilities in this specific area have changed meaningfully over time and will likely keep changing.

18Avoid Blind Create Actions on Business-Critical Flows

A Zap that goes straight from a Facebook Lead Ads trigger to a Create Salesforce Lead action, with no search step in between, will create a new Lead for every single submission regardless of whether that person already exists anywhere in Salesforce. The better pattern normalizes the incoming data first, searches Salesforce, and only then decides between update and create. "Create" should very rarely be the first Salesforce action in a lead-intake Zap handling anything the business actually depends on; it's a reasonable choice only after a search has already run and genuinely come back empty.

19Handle Repeat Form Submissions as New Events, Not New People

A person submitting a second quote request, a demo request for a different product, or a support inquiry weeks after their original contact isn't necessarily a new person, and their repeat activity shouldn't get silently discarded just because a matching record already exists. The right pattern: when an existing person is found, update their last-inquiry-date field, record the new inquiry itself as its own event, and create whatever downstream artifact fits, a Task, a Campaign Member record, or a new Opportunity, as appropriate to what actually happened. The person may not be new. The business event is new, and it deserves to be captured as one, distinct from simply updating a stale field on an existing record and calling it done.

20Separate Person Identity From Inquiry Identity

This distinction underlies most of what makes repeat-inquiry handling actually work: model person and inquiry as two separate concepts rather than creating a new person record for every form submission. In more advanced architectures, this separation gets its own dedicated structure, a custom Inquiry object, a Campaign Member record, an Activity, an Opportunity, a Task, or another custom event record, depending on what the business actually needs to track about each interaction. The person record stays singular and stable; the inquiry records accumulate underneath it, each representing one genuine business event without ever requiring a new person to exist.

21Handle Leads That Have Already Been Converted

A common, specific failure pattern: a Lead converts to a Contact, and later, the same email address submits another form. If the Zap handling that form searches Leads only, since as far as it's concerned that's always been the right object to check, the search comes back empty (the Lead no longer exists as a Lead; it's now a Contact), and a brand-new Lead gets created sitting alongside the already-existing Contact. This is precisely why the Contacts-before-Leads search order covered earlier matters as a fixed rule rather than an occasional nicety: it's the specific mechanism that catches this exact, very common scenario.

22Handle Contacts With Multiple Email Addresses

Where a Contact record carries a Business Email, a Personal Email, and a Secondary Email, decide explicitly which field is authoritative for matching purposes, and whether historical addresses should still be checked when a new inquiry arrives under a different one. This gets genuinely tricky when someone changes companies: is the person at the new domain the same Contact continuing an existing relationship, or a new business relationship worth tracking separately even though it's the same human being? There's no universally correct answer here, and matching people across companies based on name alone is a real risk of merging two distinct professional relationships into one record; when this scenario comes up, route it to human review rather than resolving it automatically in either direction.

23Handle a Changed Email Address

sarah@oldcompany.com and sarah@newcompany.com might represent the same person who's since changed jobs, a different person who happens to share a name, or the start of a genuinely new business relationship worth tracking on its own terms. None of these should get resolved by a deterministic rule alone. Build an explicit human-review path for this category of uncertain match rather than guessing, since the cost of guessing wrong, either merging two different people or losing track of an existing relationship's history, is meaningfully worse than the small delay of a quick manual check.

24Handle Shared Emails

Addresses like info@, sales@, office@, admin@, a shared family email, or a shared front-desk inbox should never serve as a definitive identity key on their own, since by design they represent more than one person, sometimes an entire organization. When a shared-pattern email is detected, require at least one additional matching field, a name, a phone number, or an external ID, before treating an incoming record as a match against anything already tied to that shared address.

25Handle Shared Phone Numbers

Shared phone numbers show up constantly in families, small businesses, shared offices, and franchise locations. As with shared emails, phone matches on their own are weak evidence; combine a phone match with name, company, email, or an external ID before treating it as confident, and route phone-only matches with no corroborating field to human review rather than auto-matching against whichever existing record happens to share that number.

26Use Salesforce Matching Rules

Salesforce Matching Rules define, natively inside Salesforce, how records are compared against each other, using specified fields and configurable matching logic, exact matching on some fields, fuzzy matching where the platform supports it on others, across Leads, Contacts, and Accounts. Matching Rules are what a Duplicate Rule references to actually decide whether two records look like a match; they're the comparison logic, not the enforcement logic. Salesforce ships standard matching rules for these objects and supports custom ones with tighter or looser criteria. Confirm the current fields and fuzzy-matching capabilities available for Matching Rules directly in Salesforce's documentation before designing custom rules around them, since exact supported matching behavior can vary by edition and has evolved over past releases.

27Use Salesforce Duplicate Rules

Duplicate Rules reference a Matching Rule and define what actually happens when that matching logic finds a potential duplicate: options generally include allowing the save while logging it, allowing with an alert shown to the user, or blocking the save outright, alongside a duplicate-record report. Confirm the exact configuration options and current defaults directly against Salesforce's documentation rather than assuming a specific behavior, since the precise UI and available actions are Salesforce's to define and can change between releases. What matters for this guide's purposes: records created or updated through Zapier's Salesforce actions are subject to these same native rules, exactly as if a human had entered the data directly into Salesforce.

28Understand Zapier and Duplicate Rule Conflicts

A specific, recurring failure pattern: Zapier searches by email, finds no exact match, and attempts to create a new record, only for Salesforce's own Duplicate Rule to detect a similar existing Contact and block the create. The instinct is to treat this as a bug to route around. It usually isn't. Salesforce is doing exactly what it was configured to do, catching a likely duplicate that Zapier's own search logic, matching only on exact email, happened to miss because the existing record used a slightly different email or a fuzzy-matching field Zapier's search wasn't checking. Route these blocked-create cases into human review rather than simply disabling the Duplicate Rule to make the error go away, since disabling it removes a real safety net, not just an inconvenience.

29Decide Deliberately When to Block vs. Allow

Reasonable candidates for blocking outright: an exact email duplicate, a matching external ID, or a matching verified customer ID, cases where the evidence is essentially conclusive. Reasonable candidates for allowing with review rather than blocking: a similar company name, a matching name alone, a shared phone number, different email addresses that might represent the same person, or what looks like a related household. False positives, blocking or merging two genuinely different people, cause real damage of their own: lost inquiries, frustrated prospects who can't get a response because their record got silently swallowed into someone else's history, and sales reps working from an incomplete or wrong picture of who they're actually talking to. Treat that risk with the same seriousness as the duplicate-record risk itself, rather than assuming the safest default is always the most aggressive matching.

30Build a Human Review Queue

Route genuinely ambiguous matches to a dedicated Duplicate Review state carrying the incoming data, the potential matching record or records, the specific reason it was flagged, direct Salesforce links, the source, a reviewer, and a recommended action for that reviewer to consider. Reasonable resulting decisions include updating the existing record, creating a new one after all, merging two records, ignoring the flag as a false alarm, or escalating to someone with more context. This queue is the release valve that lets the rest of the system stay conservative, only auto-resolving the cases where the evidence is genuinely strong, without leaving every uncertain case unresolved indefinitely.

31Add Confidence Scoring to Structure the Review Queue

A simple custom scoring model can help prioritize and route matches consistently: an external ID match scoring highest, an exact email-plus-name match close behind, exact phone-plus-company slightly lower, email alone lower still, name-plus-company weaker yet, and name alone the weakest signal worth considering at all. Score bands can then drive behavior: a high-confidence band auto-matches, a middle band routes to review, and a low band either creates a new record or routes to review depending on the business's own risk tolerance. State plainly, including to anyone else who inherits this system, that any specific scoring values are an example custom model built for this workflow, not a Salesforce native standard or an industry benchmark; the actual weights should reflect how costly a false match versus a missed match is for your specific business.

32Prevent Duplicates From Zap Retries

A Zap can retry after a timeout, an API error, a temporary Salesforce outage, or a manual replay from Zap History, and if the retry re-runs the entire create logic without checking whether it already succeeded once, it produces a second record for an event that was already fully processed. Guard against this with external IDs, consistent search-before-create logic, and, most directly, an idempotency check: before taking any create or update action, search by the source record ID specifically and check whether this exact event has already been processed. If yes, stop. If no, continue. This is a narrower, more specific check than the general Contact/Lead search covered earlier; it's asking not "does this person exist" but "have I, this specific automation, already handled this specific event."

33Prevent Duplicates From Webhook Retries

Webhooks from ad platforms, form tools, and other sources can and do send the same event more than once, sometimes due to the sender's own retry logic, sometimes due to network conditions entirely outside your control. Track each incoming webhook's event ID in a processing log or dedicated deduplication table, and check that ID before taking any Salesforce action; if it's already been recorded as processed, stop there rather than running the full create-or-update logic a second time for an event you've already handled.

34Prevent Multiple Zaps From Independently Handling the Same Lead

A business commonly ends up with several parallel intake Zaps, one from the website, one from an email parser, one from a separate marketing platform, each built at a different time by a different person, and all three can genuinely see the same underlying event and each independently decide to act on it. The structural fix is a centralized intake architecture: rather than three Zaps each independently deciding whether to create or update, route every source through one shared normalization and identity-matching layer before anything touches Salesforce. This can be built in Zapier itself using a shared Sub-Zap, in Make or n8n, through dedicated middleware, or via a custom API, and Salesforce's own external-ID-based upsert capability can serve as a final backstop even if the upstream architecture isn't fully centralized yet.

35Build a Deduplication Table

A dedicated table tracking the source system, source record ID, resulting Salesforce record ID, matched email, matched phone, created timestamp, match result, and processing status gives you the concrete record of every identity decision this system has made. It can live in Zapier Tables, Airtable, a proper database, or a Salesforce custom object, and it directly supports idempotency checks, troubleshooting a specific record's history, ongoing reconciliation, and general audit history, none of which is really possible to reconstruct after the fact without it.

36Use Upsert Where the Platform Genuinely Supports It

The general upsert concept, check whether a record exists by external ID, update if it does, create if it doesn't, in a single operation, is directly supported by Salesforce's own REST API through the sObject Rows by External ID resource, which performs exactly that check-then-create-or-update behavior server-side based on the value of a specified External ID field. Whether your specific integration tool exposes that same single-call upsert behavior, versus requiring you to build the find-then-branch pattern manually across separate search, update, and create steps, varies by tool and by object, so verify current behavior directly rather than assuming every platform offers a genuine one-step upsert equivalent to what Salesforce's own API provides natively.

37Decide Whether Zapier or Salesforce Should Own Deduplication

Three broad architectures are worth naming explicitly. A Zapier-first approach has Zapier search and decide before anything reaches Salesforce, giving you full visibility and control over the logic but putting the entire burden of correctness on the Zap. A Salesforce-first approach has Zapier submit records more or less directly and lets Salesforce's own Matching and Duplicate Rules govern what happens, which leans on native Salesforce functionality but gives you less granular control over routing decisions like which existing record to update versus which action to take on an ambiguous match. A hybrid approach has Zapier perform the deterministic, high-confidence search-and-match logic covered throughout this guide, while Salesforce's native Duplicate Rules serve as a secondary, independent safety net catching whatever Zapier's search criteria happened to miss. For business-critical lead flows, the hybrid model tends to be the strongest, precisely because it doesn't rely on either layer being perfect on its own.

38Handle Duplicate Accounts Specifically

Search for existing Accounts based on domain, an external business ID if one exists, a company registration number where that's tracked, exact normalized company name, and address, and avoid a scenario where "Acme," "Acme Inc," "Acme LLC," and "Acme Corporation" end up as four separate, unreviewed Account records simply because each one arrived through a slightly different form with a slightly different self-reported company name.

39Handle Duplicate Opportunities

Duplicate Opportunities tend to show up when the same inquiry triggers Opportunity creation more than once, whether from a Zap retry, a Contact submitting essentially the same request twice, or several separate automations each independently creating an Opportunity for what's really one underlying business event. As with Leads and Contacts, use a unique business-event identifier, an inquiry ID mapped to an Opportunity external reference field, for instance, so a retry or a second trigger can be checked against what's already been created rather than blindly generating another Opportunity for the same deal.

40Preserve Lead Source and Attribution When Updating

When an existing Contact or Lead gets updated rather than replaced by a new record, resist overwriting the Original Lead Source, the original Campaign, or first-touch attribution data with whatever the new inquiry's source happens to be. Instead, preserve a First Source alongside a Latest Source, log the new inquiry's own source separately, and maintain campaign history rather than letting it collapse to just the most recent touch. Duplicate prevention that quietly destroys marketing attribution in the process of avoiding a duplicate record has just traded one data-quality problem for a different, often more consequential one, since attribution feeds directly into the pipeline and revenue reporting the business actually uses to make decisions.

41Preserve Activity History Through Every Match Decision

Whatever matching and update logic runs, confirm that emails, calls, Tasks, meetings, Campaign Membership, and Opportunities all stay correctly attached to the person they actually belong to. A matching decision that updates the right Salesforce record but somehow leaves a newly created Task pointing at a different, stale record accomplishes nothing; the point of avoiding the duplicate was to keep this person's full history in one place, and that only holds if every piece of the workflow, not just the core Lead or Contact update, resolves to the same record consistently.

42Log Every Duplicate Decision

Record the incoming source, the incoming source ID, which matching method resolved the decision, which specific fields matched, the resulting existing Salesforce ID if one was found, the action actually taken, a confidence score if you're using one, a timestamp, which version of the matching logic ran, and whether a human overrode the automated decision. This log is what lets a manager answer a genuinely common question after the fact: why did this new inquiry update an existing Contact instead of creating a fresh Lead? Without a decision log, that question has no answer beyond re-reading the Zap's logic and guessing what probably happened for this specific record.

43Monitor Duplicate Rates by Source

Track, per source, total inquiries, how many resulted in a genuinely new record, how many matched and updated an existing person, how many landed in ambiguous review, and how many were flagged as outright duplicate attempts. A pattern like a website generating a 12 percent repeat-inquiry rate, Meta running closer to 4 percent duplicates, and an event-list import spiking to 28 percent duplicates isn't just a curiosity; a duplicate rate that high on an imported list usually points at a reused or stale contact list, poor filtering at the source, an integration architecture problem specific to that source, or a campaign that's inadvertently re-targeting existing customers. Source-level duplicate-rate monitoring is often what surfaces these upstream problems well before anyone notices the resulting mess directly in Salesforce.

44Build a Data Quality Dashboard

A useful ongoing view tracks duplicate Lead and Contact counts, duplicate Account counts, Leads found to be matching an existing Contact (the specific converted-Lead failure mode covered earlier), records missing an external ID, the current count of ambiguous matches, the size of the human-review backlog, duplicate-creation attempts broken down by which Zap generated them, duplicate rate by source over time, and how often Salesforce's own Duplicate Rules are blocking a Zapier-attempted create. That last metric specifically tends to be an early warning sign worth watching closely, since a rising block rate usually means an upstream Zap's search logic has drifted out of sync with what Salesforce's native rules are actually catching.

45Clean Up Existing Duplicates, Carefully

Historical cleanup is a genuinely different exercise from prevention, and it deserves its own careful process rather than a bulk merge run over a weekend. Identify a duplicate set, choose a master record deliberately, review current ownership, review attached activities, review any associated Opportunities, review Campaign Membership history, then merge or correct, and finally verify that every downstream integration still resolves correctly against the surviving record. Skipping any one of these steps, particularly the final verification, is how a technically successful merge inside Salesforce quietly breaks three external integrations that were still referencing the record that just got merged away.

46Choose the Master Record Thoughtfully

When merging, weigh which record has an active Account relationship, which has the more complete data, which reflects the currently correct owner, which carries the more significant activity or Opportunity history, which has a documented consent or compliance history worth preserving, which holds the original, correct source attribution, and which one external systems are actually still referencing by ID. "The newest record wins" is a genuinely poor default rule in practice, since the newest record is often the least complete one, created hastily by whichever automation most recently mishandled this person, while the older record frequently holds the richer, more accurate history.

47Fix the Automations Before Cleaning the Historical Data

Cleaning up today's duplicates while the underlying Zaps that created them are still running unchanged simply means tomorrow's Salesforce data will look the same as today's did before the cleanup. Sequence the work deliberately: fix the creation logic first, test it thoroughly, monitor it running correctly for a real stretch of time, and only then invest in cleaning up the historical duplicates that accumulated before the fix went in. Cleaning first is a genuinely common and genuinely wasted effort.

48Handle Merge Consequences for External Systems

When two Salesforce records get merged, external systems that previously referenced the losing record's ID don't automatically know that record is gone; they'll keep pointing at an ID that either no longer resolves or silently redirects, depending on Salesforce's specific merge behavior, which is worth confirming directly rather than assuming. Review Zapier workflows, connected marketing platforms, billing systems, any downstream data warehouse, customer portals, and integration tables for lingering references to the merged-away record ID before considering a cleanup effort complete. This is precisely why deduplication has real integration consequences beyond the CRM itself, and why merge decisions shouldn't be made purely from inside Salesforce without checking what else depends on the record being removed.

49Build Real Error Handling

Handle a Salesforce search that fails outright, a search returning no match, a search returning multiple ambiguous matches, a Duplicate Rule blocking a create, Salesforce authentication failures, missing email or invalid phone data, a missing external ID, a Zap timeout, a search step failing independently of the overall run, a record that's since been merged, a record that's been deleted, and permission errors. The unifying principle across all of these: when the duplicate check itself fails or returns something uncertain, do not fall back to blindly creating a record anyway. Retry automatically if the failure looks transient and safe to retry; if it's still uncertain after that, route to the human-review queue and let a person resolve it, rather than letting an error state default to "just create it and move on," which is exactly how duplicate rates creep back up even after the core logic has been built correctly.

50Monitor the Workflow

Track search failures, Duplicate Rule blocks, ambiguous-match volume, the rate of new-record creation versus update, general automation errors, the overall duplicate rate, and the timestamp of the last successful run, ideally feeding into the same broader Salesforce and Zapier automation-health monitoring the rest of your stack already uses. A duplicate-prevention system that silently stops working, an auth token expiring, a search step quietly failing, produces exactly the same symptom as never having built it in the first place, just with a delay before anyone notices.

51Reconcile Source Events Against Salesforce Outcomes

Periodically compare the count of source events against how the system actually resolved them: 100 source inquiries breaking down into, say, 82 genuinely new people, 16 existing people correctly updated, and 2 sent to review, accounts for all 100 events even though only 82 resulted in a new Lead. This is a meaningfully stronger, more accurate reconciliation target than naively expecting 100 new Leads to have been created; a healthy duplicate-prevention system should be producing fewer new records than raw inquiry volume, precisely because it's correctly recognizing repeat and existing contacts rather than creating a fresh record for every single event.

52Testing Matrix

Before trusting this system with real leads, test: a brand-new person with no prior history, an existing Lead, an existing Contact, an existing Account, an existing customer, an exact email duplicate, a matching phone with a different email, a matching name at a different company, a shared email, a shared phone number, a company change, an email change, a previously converted Lead, a duplicate webhook event, a Zap retry, a manual Zap replay, multiple genuinely matching Contacts, a Salesforce Duplicate Rule actively blocking a create, an external-ID match, missing email, missing phone, an Account-level match, a high-value existing customer scenario, Opportunity creation, a record that's already been merged, and a Salesforce authentication failure mid-run.

53Common Mistakes

The most damaging mistake is using Create as the first Salesforce action in a business-critical intake Zap, with no search step in front of it at all. Close behind: searching Leads but never checking Contacts, which reliably fails on every converted Lead; matching only by name or only by phone, both weak signals in isolation; ignoring the converted-Lead scenario as a distinct case worth handling; skipping external IDs and source record IDs entirely, which removes the deterministic anchor everything else in this guide depends on; no retry protection, so a single transient failure can produce a duplicate on replay; disabling Salesforce Duplicate Rules because they're throwing errors, rather than treating those errors as a signal to route to review; no human-review path at all, forcing every ambiguous case into either a false match or a missed one; overwriting existing ownership or first-touch attribution on update; creating a brand-new person record for what was actually a repeat inquiry from someone already in the system; running multiple Zaps with inconsistent, uncoordinated matching logic; cleaning up historical duplicates before fixing the automation that's still creating new ones; blindly replaying failed Zap tasks without checking whether they'd already partially succeeded; and, tying all of it together, no duplicate-rate reporting, no decision logging, no ongoing monitoring, and no documentation of what the matching policy actually is.

54Implementation Roadmap

Phase 1: Duplicate Audit

Review existing Leads, Contacts, and Accounts for current duplicate volume, audit every Zap currently writing to Salesforce, and review existing Salesforce Matching and Duplicate Rule configuration.

Phase 2: Identity Strategy

Define the matching hierarchy, external ID strategy, email and phone normalization rules, Account-matching rules, and an explicit policy for handling ambiguous matches.

Phase 3: Salesforce Configuration

Configure external ID fields, review and adjust Matching Rules and Duplicate Rules, establish review-status fields, and add the reporting fields the rest of this system depends on.

Phase 4: Zapier Search Logic

Build normalization, Contact search, Lead search, Account search, Paths-based branching, and the resulting create-or-update logic for every intake source.

Phase 5: Idempotency

Add source record IDs, event IDs, a deduplication table, and retry protection so replays and webhook retries can't silently produce duplicates.

Phase 6: Human Review

Build the ambiguous-match queue, alerting for new review cases, a defined review process, and an audit trail of every decision made through it.

Phase 7: Reporting

Build the duplicate dashboard, source-level duplicate-rate reporting, review-backlog visibility, and automation-health monitoring.

Phase 8: Historical Cleanup

Only after prevention logic is confirmed working: identify existing duplicate sets, merge carefully with a deliberate master-record process, verify every dependent integration, and document what changed.

55The Bigger Picture

Salesforce data quality tends to get treated as a housekeeping problem, something to clean up eventually when someone gets around to it. It's really an operational and revenue problem hiding behind a database-hygiene label. Duplicate records split activity history, confuse ownership, produce contradictory outreach to the same prospect, and quietly corrupt the pipeline and attribution numbers the business uses to decide where to invest. None of that gets fixed by an occasional merge project; it gets fixed by making sure the intake architecture itself, every Zap, every form, every webhook, consistently knows when to create, when to update, and when to stop and ask.

The businesses that get this right treat identity matching as shared infrastructure, one policy, applied consistently everywhere data enters Salesforce, rather than a setting buried inside each individual Zap. Once that infrastructure exists, adding a new lead source stops being a data-quality risk and becomes exactly what it should be: one more input feeding into a system that already knows how to handle it correctly.

56How New Motion IT Helps

Businesses typically come to us once the symptoms are already visible: sales reps working from multiple versions of the same prospect, marketing attribution that doesn't add up, or a Salesforce database that's grown messier every quarter despite periodic cleanup efforts. A Salesforce + Zapier Duplicate Prevention and Data Quality engagement typically includes a duplicate-data audit, a full review of existing Zapier workflows and Salesforce Matching and Duplicate Rule configuration, an identity-matching strategy with a defined external ID design, search-before-create architecture across Leads, Contacts, and Accounts, repeat-inquiry handling that preserves rather than discards genuine business events, idempotency and webhook duplicate protection, safe replay logic, a human-review workflow for ambiguous matches, duplicate reporting, a historical cleanup strategy sequenced correctly after prevention is confirmed working, documentation, and team training.

If your Salesforce database keeps filling with duplicate Leads and Contacts, the underlying problem usually isn't the CRM, it's the way your integrations decide when to create a new record in the first place. Reach out to schedule a Salesforce Duplicate Prevention and Zapier Data Quality Audit, covering your existing duplicate Leads, Contacts, and Accounts, your current Zapier workflows and their find-or-create logic, Matching and Duplicate Rule configuration, external ID coverage, source record ID usage, the risk your current failed-task replay behavior carries, how repeat inquiries are actually being handled today, and what a responsible historical cleanup would involve.