Configure Salesforce duplicate rules before imports

Review Salesforce duplicate rules before imports, portals, and lead capture changes. Start with matching logic, rule actions, exceptions, and reporting.

Duplicate rules are not cleanup tools. They are intake controls.

If rules are configured after imports, portals, web forms, or service workflows go live, the org has already accepted the bad data. The admin is left to clean up duplicate Contacts, Leads, Accounts, or Person Accounts after users have built work around them.

We see this pattern often in mid-market Salesforce orgs. A team adds a new intake source: a form, Experience Cloud portal, call center workflow, managed package, or middleware job. Records start arriving. Users report duplicate Contacts or Leads. The admin tightens a duplicate rule. Then valid work starts getting blocked.

That order is backwards.

Duplicate management belongs in intake design. Review it before new records enter Salesforce at scale.

What are Salesforce duplicate rules?

Salesforce duplicate rules define what happens when Salesforce finds a possible duplicate during record creation or update. Matching rules decide whether records look alike. Duplicate rules decide whether Salesforce allows, alerts, blocks, or reports the action.

That distinction matters.

A MatchingRule answers: do these two records appear to match?

A DuplicateRule answers: what should Salesforce do about it?

Salesforce includes standard matching rules and duplicate rules for common objects, including Accounts, Contacts, and Leads. Many orgs also add custom rules for local business rules.

Common examples include:

• Match Contacts on exact email address.
• Match Leads on email address and company.
• Match Accounts on website domain.
• Match Person Accounts on phone and mailing postal code.
• Match Contacts on normalized phone number and last name.

The risk is not that duplicate rules exist. The risk is that they exist without a clear operating decision.

A rule that blocks Contact creation when email matches may work for a B2B sales team. It may fail for a service team that handles shared family email addresses. A rule that allows duplicate Leads with an alert may be acceptable for inside sales. It may create reporting problems if Lead conversion rules are weak.

The configuration has to match how the business handles records.

What should admins check before a Salesforce import?

Admins should review matching rules, duplicate rule actions, bypass needs, and reporting settings before any material import. The goal is to decide which duplicates should be blocked, which should be flagged, and which should be allowed for later review.

Start with the object being imported. In many orgs, that means Leads, Contacts, Accounts, Person Accounts, Cases, or a custom intake object.

Then check four areas.

1. Matching logic

Open the active matching rules for the target object. Confirm which fields are used and whether the match is exact or fuzzy.

Common match patterns include:

• Email exact match
• Phone fuzzy match
• Account name fuzzy match
• Website exact match
• Mailing address partial match
• First name, last name, and date of birth for regulated service contexts

Use fuzzy logic carefully. It can catch variations like “Acme Inc.” and “Acme Incorporated.” It can also create false positives when account names are short, generic, or regional.

If the import comes from a system with different formatting, clean the data before testing. Phone numbers, state names, postal codes, and website domains can all change match behavior.

2. Rule action

For each duplicate rule, check whether Salesforce is set to:

• Allow the record and show an alert
• Block the record
• Report the duplicate
• Apply different behavior on create versus edit

Blocking sounds clean. It can also create operational risk during imports and integrations. A blocked insert can interrupt a Data Loader job, break middleware processing, or force users into manual workarounds.

For imports, an alert-only rule may be safer if the team has a review queue. For front-line users, blocking may be appropriate if the match is precise and the next step is clear.

The key is to avoid surprise. If a rule blocks, the person or system creating the record needs a defined resolution path.

3. User and profile exceptions

Duplicate rules can apply based on user conditions. That is useful, but it creates admin debt when exceptions are undocumented.

Common exceptions include:

• Integration users
• Data migration users
• System administrators
• Partner portal users
• Internal service agents
• Marketing operations users

Do not treat exceptions as permanent fixes. If an integration user bypasses duplicate rules, the integration needs its own duplicate handling. If a migration user bypasses duplicate rules, the imported records still need post-load review.

Exceptions should be named, documented, and dated. If nobody knows why a profile is excluded, test the rule without that exception in a sandbox before changing production.

4. Duplicate reporting

If duplicate rules are set to report possible duplicates, Salesforce can create duplicate record sets and duplicate record items. These records give admins a queue for reviewing duplicate clusters after the fact.

Check whether your duplicate rules are configured to report matches. If not, users may see alerts without giving operations a workable review process.

Useful objects and metadata names include:

• DuplicateRule
• MatchingRule
• DuplicateRecordSet
• DuplicateRecordItem

For cleanup projects, duplicate record sets are often more useful than a one-time spreadsheet export. They show which records Salesforce believes are related, based on the configured matching logic.

How should duplicate rules work with portals and forms?

Duplicate rules for portals and forms should be designed around the source system, user experience, and failure path. A public form, Experience Cloud page, or external intake tool should not depend on an alert that only makes sense inside Salesforce.

A Salesforce user can see a duplicate warning, open the possible match, and decide what to do. An external form user cannot. An API process may receive an error but have no logic to search, update, or route the existing record.

Before connecting an intake source, answer these questions:

• What object does the source create?
• Is the source allowed to update existing records?
• Which field is the durable identifier?
• What happens when email matches but name does not?
• What happens when phone matches but email is blank?
• Who reviews possible duplicates?
• Where are failed submissions logged?

For a support portal, the right answer may be to find an existing Contact and create a new Case. For a lead form, the right answer may be to create a Lead, flag it as a possible duplicate, and route it to marketing operations. For a partner intake form, the right answer may be to require sign-in before submission.

Do not force every source into the same duplicate rule. Internal users, public forms, partner portals, and integrations have different error handling needs.

If the source is external, test duplicate behavior through the external path. Creating records manually in Salesforce Setup does not prove the portal, middleware, or API job will behave correctly.

What is a practical duplicate rule review process?

A practical review starts with inventory, test data, and ownership. Do not begin by changing rule settings in production.

Use this sequence.

Step 1: Inventory active rules

List every active duplicate rule by object. Capture:

• Rule name
• Object
• Matching rule
• Action on create
• Action on edit
• Whether reporting is enabled
• User or profile conditions
• Last modified date
• Business owner

If a rule has no business owner, assign one before changing it.

Step 2: Map intake paths

For each target object, list every way records enter Salesforce.

Examples include:

• Manual user entry
• Data Import Wizard
• Data Loader
• Web-to-Lead
• Experience Cloud forms
• Middleware
• External portal
• CTI or call center workflow
• Managed package
• Scheduled batch job

Then mark which paths create records, update records, or do both.

This is where hidden risk often appears. A duplicate rule that works for manual entry may cause failures in an external portal. A rule that works for marketing imports may slow down service agents.

Step 3: Build a duplicate test set

Create test records that represent real match conditions. Include clean matches and edge cases.

Examples include:

• Same email, different phone
• Same phone, different email
• Same company, different domain
• Same person, nickname variation
• Shared household email
• Blank email with matching phone
• Existing Contact with new Lead submission

Run the test set in a sandbox through each intake path. Record whether Salesforce allows, alerts, blocks, or reports each case.

Step 4: Decide the remediation path

Every duplicate outcome needs an owner.

If Salesforce blocks a record, who resolves it? If Salesforce allows and reports it, who reviews the duplicate record set? If an integration fails, where does the error go?

A duplicate rule without an operating process becomes background noise. Users ignore alerts. Integration errors sit in logs. Reports stay dirty.

Step 5: Document the final decision

Document the rule in plain English. Include the reason for the setting.

A useful note looks like this:

“Contact duplicate rule blocks manual Contact creation when email is an exact match. Integration user is excluded because the external portal runs pre-insert lookup logic and creates Cases against existing Contacts.”

That sentence gives the next admin enough context to avoid breaking the process later.

What should you do this week?

Before the next import, portal change, or lead capture update, review four things: matching logic, rule action, exception list, and reporting behavior.

The right duplicate rule is not always the strictest one. It is the one that protects data quality without blocking valid work.