Duplicate records (e.g., the same store visit logged twice, or the same customer account entered twice) can clutter your FieldKo data and skew reports. Salesforce provides native Duplicate Management tools to identify and prevent duplicates using Matching Rules and Duplicate Rules.
As an admin, you can configure these rules to catch duplicates among FieldKo objects like Visits, Tasks, or Accounts. You can also merge duplicates to clean up existing data. This article will guide you through using Salesforce’s duplicate management to keep FieldKo data clean – focusing on standard Salesforce functionality (no third-party apps needed).
Duplicate Rules versus Matching Rules
It’s important to understand the difference:
Matching Rules define how to compare records to decide if they’re duplicates. For example, a matching rule might say “Contact First Name fuzzy match AND Last Name exact AND Email exact” – meaning if those fields are similar, the records are considered a potential duplicate. Think of a matching rule as the criteria or recipe for identifying dupes.
Duplicate Rules specify when to run those matching rules and what to do when a duplicate is found. A duplicate rule uses one or more matching rules to check records during create or edit (and can also be run on a batch of existing records via Duplicate Jobs in higher editions). The duplicate rule can either alert the user (allowing them to proceed but warning of dupes) or block the save of the record. Think of the duplicate rule as the chef using the recipe – it decides when to cook (run) and what to do with the outcome.
In short: Matching rules = how to identify a dupe; Duplicate rules = when to check and how to react.
Setting Up Duplicate Detection for FieldKo
Salesforce comes with some standard matching rules (for Accounts, Contacts, Leads) and duplicate rules out-of-the-box (e.g., a rule to alert on duplicate contacts). For FieldKo-specific objects (like a custom Visit__c object), you will create custom rules.
1. Create a Matching Rule:
Go to Setup > Matching Rules. Click “New Matching Rule.”
Choose the object you want (e.g., Visit__c or Account if focusing on accounts).
Define the criteria: You can add one or more fields to compare. For example, for Visit__c, you might consider a combination like Account (exact match) AND Visit Date (exact match) as a way to catch two visits to the same account on the same date (which might indicate a duplicate entry). For Accounts, you might use Account Name (fuzzy) AND Billing City (exact) or something similar to catch slight name variations.
For each field, choose the matching method: Exact (must be identical), Fuzzy (Salesforce will do partial matches, useful for names), or other algorithms (e.g., Email has a specific matching algorithm).
Save the rule (it will be in “Inactive” status initially). Activate the matching rule when you’re ready – activation will index the object’s data for matching, which might take some time if you have a lot of records. (Note: Only one matching rule can be active per object at a time, but each rule can consider multiple fields.)
2. Create a Duplicate Rule:
Go to Setup > Duplicate Rules. Click “New Duplicate Rule” and select the object (e.g., Visit__c or Account).
Give it a name (e.g., “Duplicate Visit rule”).
In the rule, you’ll specify:
Matching Rule: choose the matching rule you created (or a standard one for that object). You can actually add up to 3 matching rules in one duplicate rule for more complex scenarios – but usually one is sufficient.
Action on Create and Action on Edit: decide if you want to Allow (but alert) or Block the user from saving a duplicate. For FieldKo, you might choose to Allow and Alert (so the user can override if needed) for something like Visits, but Block duplicates for Accounts (to prevent two accounts for the same store). It depends on your business process.
Alert Text: If you’re alerting, you can customize the message the user sees (e.g., “Possible duplicate visit detected! Please check existing records.”).
Record-Level Security: You can choose whether to bypass sharing rules (usually keep the default so that users are alerted even if the potential duplicate is one they can’t normally see).
What to do with duplicate record sets: There’s an option to create a Duplicate Record Set item. (Salesforce can log duplicates it finds into a Duplicate Record Set for reporting/admin review.)
Also, you’ll see an area to include or exclude certain records: e.g., filter conditions (“Only apply to Visits where Status = Completed”, etc.) if needed.
If you want cross-object matching (like flag a duplicate Visit against an Account, which is a bit unusual), Salesforce doesn’t directly match across two different custom objects in one rule. Cross-object matching in standard Salesforce is mainly for Leads vs Contacts vs Accounts. For example, the standard Lead duplicate rule uses a cross-object matching rule to catch leads that duplicate contacts. If you’re doing Accounts and you want to catch dupes against Leads (perhaps FieldKo doesn’t need that), you’d activate the standard rules provided.
For accounts, Salesforce provides a Standard Account Duplicate Rule which you can enable – it uses a fuzzy match on Account Name and exact on phone or website. Similarly, standard rules exist for Contacts and Leads, including cross-object matching (Lead vs Contact). You can use those or customise your own for FieldKo specifics.
Activate the duplicate rule.
Now, when users (or integrations) try to create or edit a record that meets the matching criteria, Salesforce will intervene. If you set to “Alert”, the user will see a warning popup listing the potential duplicates and can decide to cancel or save anyway. If “Block”, the save is prevented and the user is told to resolve the duplicate.
Cross-object Matching (Lead to Contact etc.): As mentioned, Salesforce’s standard duplicate rules can check across objects in some cases. For example, the standard duplicate rule for Contacts will also catch a Lead with the same email as a Contact (and vice versa), preventing siloed duplicates. To leverage cross-object, use the out-of-the-box rules or set up matching rules on each object that use the same logic (e.g., an Email matching rule on both Lead and Contact, then a duplicate rule on Lead that also references matching contacts). This way, FieldKo leads captured aren’t duplicating existing contacts.
Handling Duplicates and Merging Records
Preventing new duplicates is half the battle. You might already have some duplicate records in the system that need clean-up. For example, two Account records for the same customer (perhaps entered by different reps), or duplicate Visit entries. Here’s how to manage them:
Reviewing Duplicate Alerts: As an admin, you can review the log of duplicates if you enabled “Report or Action” on the duplicate rule. Check the Duplicate Record Sets in Setup – you’ll see groups of records Salesforce marked as duplicates. This can help you identify candidates for merging.
Merging Duplicates (Accounts, Contacts, Leads): Salesforce has a native merge function for Accounts, Contacts and Leads:
To merge Accounts: go to the Accounts tab -> click Merge Accounts (in Lightning Experience, you can find this under account tools). You’ll be prompted to search for the duplicate accounts by name, select up to 3 accounts, then proceed to a merge screen. You choose one account as the master (or “primary”) and choose which field values to keep from each record, then merge. The other account records will be deleted and the master record retains the chosen data.
To merge Contacts: Salesforce allows merging contacts that share the same Account. On an Account record page, there’s a Merge Contacts action (in Lightning, find it under the account’s Contacts related list options). This lets you select 2 or 3 contacts under that account to merge in a similar interface. In Lightning, you can also use the Potential Duplicates component on a contact record – if Salesforce has identified duplicates (via the duplicate rule), you can click Review Duplicates and then Merge. You can merge up to three contacts at a time.
To merge Leads: Similar process via the Leads tab -> Merge Leads.
When merging, take care to pick the correct “winner” record and field values. Salesforce will keep all related records (like opportunities, activities) attached to the merged survivor and delete the other duplicates. Note that for custom objects (like a custom Visit__c), Salesforce does not have a built-in merge UI. Merging those would require either manual data move & delete, or using a third-party dedupe tool. For FieldKo Visits, you might instead prevent duplicates via rules and manually delete any duplicates that slipped in.
Manual Merge Workflows for FieldKo Objects: If you discover duplicate Visit records (or other custom objects) with no merge tool, your process might be:
Run a report or list view filtered for suspected duplicates (maybe same Name or date).
Have users or admins identify which one to keep.
Consolidate any unique info (if one has some fields the other doesn’t, you might copy data).
Delete the extra record(s).
If this is a frequent issue, consider if a custom Visualforce or Lightning component can be built to streamline it, or adjust the data entry process to avoid the dupes.
Duplicate Job (for batch detection): In Salesforce Lightning, if you have Performance or Unlimited Edition (or an add-on), there’s a feature to run a Duplicate Job on an object which scans all records using a matching rule and produces Duplicate Record Sets for review. This is useful for a one-time clean up of a large dataset. If available, you could run a duplicate job on Account or Visit and then review/merge as needed.
Best Practices
Tune your matching rules: If you get too many false positives (things flagged as duplicates that aren’t), adjust the criteria (maybe add another field or switch from fuzzy to exact on a field). If you miss duplicates, consider loosening criteria.
User Training: Educate FieldKo end users on what the duplicate alerts mean. For example, if a sales rep tries to create an Account that triggers an alert, they should know to check the existing record instead of blindly creating another.
Merge Permissions: By default, users need certain permissions to merge (e.g., Delete on the object and “Modify All” or be record owner in some cases). Ensure your profile/permission sets allow the right users (maybe admins or managers) to merge records. There’s also a specific permission “Merge Records” in Lightning for accounts/contacts/leads.
After Merging: Tell users that merging will delete the losing records. They should be aware that any references to the old record might need updating (Salesforce handles most related lists, but if external systems had the old ID, those need update).
By implementing duplicate rules for FieldKo data, you prevent future duplicates at entry – Salesforce will either alert the user or stop the save, keeping your data cleaner. And by merging existing dupes, you ensure you have a single source of truth for each entity (one Account per customer, etc.). This leads to more accurate reports and less confusion for users.