Merge Rules
Merge rules are the field-level instructions that decide which value survives in each field when duplicate records in a CRM are merged into one. They're also called survivorship rules, field merge rules or merge logic. One rule might keep the newest phone number, another the longest company name, and another every address in a list of email addresses.
Merge rules work together with the primary record, the record that survives the merge. The primary record supplies a starting value for each field, and merge rules decide where a value from another record should take its place. Because the rules are saved, the same logic applies to each merge, including bulk and scheduled merges, instead of a person picking values by hand every time. That makes them the part of deduplication logic that decides whether a merge keeps the best data or loses it.
See how Dedupely picks the winning value in each field in your CRM
What Are Merge Rules?
Merge rules are the part of a merge that works field by field. Matching decides which records are duplicates, and the choice of primary record decides which one survives. Merge rules then settle each field where the records disagree.
Take two company records for Acme. The first is named "Acme," has "N/A" as its phone number and the lifecycle stage Customer. The second is named "Acme Corporation Inc.," has the phone number (555) 010-2000 and the stage Lead. If the first record survives and keeps all of its values, the merged record reads "Acme," "N/A" and Customer. With three rules (longest name wins, placeholders lose, and the stage comes from the customer record), it reads "Acme Corporation Inc.," (555) 010-2000 and Customer.
There are a few common approaches, and many setups mix them, one per field:
- Keep the primary record's value. Simple and predictable, and the merged record looks like the one you chose to keep.
- Most recent wins. Suits data that changes, such as job titles and phone numbers.
- Most complete or longest wins. Keeps full names over initials and abbreviations.
- Source or field-based priority. A value wins because of another field, such as a status or stage, which suits teams with a clear system of record.
- Append. Combines the values in multi-value fields, so no working email address is dropped.
- Treat blanks and placeholders as missing. Keeps a real value over an empty field or "Unknown."
How Merge Rules Work
When a duplicate set is merged, merge rules run through the same few steps for each field:
- Start from the primary record. The surviving record is picked first, for example the oldest, the newest, the last updated, the one with the most field data, or one that meets a condition. Its values are the starting point.
- Look for a rule on the field. A field without its own rule falls back to a default, such as the primary record's value or the CRM's own merge logic. Read-only fields, such as system fields, often can't take a rule at all.
- Rule values out. Many tools let a value lose when it meets a condition, such as a blank, a placeholder like "N/A" or a toll-free number. Rules that remove candidates often run before rules that pick a winner.
- Pick the winner. The remaining values are compared on the field's rule: the newest, the longest, the one from a trusted record, or the one from a record whose lead stage or status meets a condition. When several conditions are set, they often run in order, and the first one that applies decides.
- Combine multi-value fields. For fields built to hold several values, the values from each record are appended instead of one being chosen.
- Preview, then write. Many tools show the merged record before anything changes. The winning values are then written to the surviving record in the CRM.
Some tools also let rules apply to all merges or only to one duplicate search, so a strict search and a looser one can follow different logic.
Why Merge Rules Matter for CRM Teams
Merge rules decide what the CRM shows after a cleanup, and they decide it the same way across hundreds or thousands of merges. A good rule repeats its good result each time. A poor one repeats its mistake just as often: an old phone number replaces the current one, a customer's stage goes back to Lead, or "N/A" survives over a real value. Each of those errors sits on a record that now looks clean, so it's harder to find than the duplicate was.
The fields merge rules decide feed the rest of the CRM. Lifecycle stage and status drive reports and forecasts, owner drives routing and commissions, and email and phone decide whether outreach reaches anyone. A stage that moves backward in a merge drops a customer out of a report; an owner that changes sends the account to the wrong rep.
Without rules of your own, the outcome depends on the merge logic of the CRM or tool doing the merge, and that logic varies. The same duplicate set can come out differently in two systems, and the team can't always say why a value won. Saved rules make each result explainable: anyone can see which rule kept which value. Because many merges are hard to reverse, setting those rules before merging costs less than fixing records after.
Getting Started With Merge Rules
Start with the fields that matter most to reporting and routing: email, phone, owner, lifecycle or lead stage, address and company name. For each one, decide what makes a value the better one. It might be newer, more complete, from a trusted record, or simply not blank.
Keep the primary record's value as the default for the other fields, and add rules one field at a time. Let blanks and placeholders such as "N/A" or "Unknown" lose to real values, take every part of an address from one record so a street isn't paired with another record's city, and append values in multi-value fields instead of choosing one.
Before merging in bulk, preview the merged record for a few real duplicate sets and check each field where the records disagree. If a strict search and a looser one need different logic, scope the rules to each search. Look at the rules again whenever a new field, data source or process is added.
In Dedupely, Merge Rules carry out this approach for each object: you set the Primary Record and a rule per field, and suggested rules such as "Placeholders lose" or "Newest wins" can be applied or dismissed field by field. A preview of the merge result shows the winning values while you build a rule, before anything changes in your CRM.
Key Takeaways: Merge Rules
Merge rules decide which value survives in each field when duplicate records merge. They start from the primary record's values and change a field only where a rule says another value is better: the newest, the most complete, the one from a trusted record, or any real value over a blank or placeholder. Multi-value fields can append values instead. Saved rules apply the same logic to each merge, so they matter most when merging in bulk or on a schedule. In Dedupely, Merge Rules are set per object, with the Primary Record, a rule per field, and Custom Win and Lose Rules that can be scoped to one Duplicate Search. Suggested rules and a preview of the merge result show what each merge keeps, Custom merge covers one-off sets by hand, and Merge History records each merge.
Frequently Asked Questions About Merge Rules
Which value is kept when you merge records in a CRM such as HubSpot, Salesforce or Pipedrive?
Unless you set merge rules, the CRM's own merge logic decides, and that logic varies from one CRM to another. Some native merge tools keep the surviving record's values, some let you pick values on the merge screen, and many keep a filled value over a blank one. Record IDs differ too: many CRMs keep the surviving record's ID, while HubSpot gives the merged record a new one. To control the outcome, set a rule for each field that matters, such as the newest phone number or the stage from the customer record, and preview a merged record before merging in bulk. In Dedupely, without Merge Rules, merges follow the CRM's own logic, which often keeps the most recent values, though it depends on the CRM, and blank values never win. With Merge Rules, you set the Primary Record and a rule per field, and the in-line preview (winning values in bold) and the Preview Merge panel show the result before merging.
How do you set merge rules without losing data?
Set rules that never let an empty or filler value beat a real one, and check the result before merging in bulk. Let blanks and placeholders such as "N/A" lose, append values in multi-value fields instead of choosing one, keep the newest value in fields that change, and take every part of an address from one record. Then preview a few merged records from real duplicate sets, especially the ones where the records disagree on several fields. This matters because many merges are hard or impossible to reverse. In Dedupely, blank values never win a merge, the "Placeholders lose" suggestion makes filler values lose, and Append combines the CRM's own multi-value fields, such as Additional email addresses in HubSpot. Merges can't be undone, so Merge History keeps each merge's original records and values, with a CSV download you can use to restore values by hand.
What happens to the merged record if you don't set merge rules?
The merge falls back to default logic, often the CRM's own, so the result depends on the system doing the merge. That default may keep the surviving record's values, the most recent values or the filled value over a blank, and it isn't always the same from one CRM to another. For most fields that's fine, but for stage, owner, phone and address, the default can keep an older or weaker value. Setting rules on those few fields gives you a predictable result without writing a rule for each field. In Dedupely, you don't need custom rules to start merging. Without Merge Rules, Dedupely follows the CRM's own merge logic, which often keeps the most recent values and the oldest Record ID, but not always. Blank values never win, with or without Merge Rules. HubSpot creates a new ID on every merge. Suggested rules, such as "Primary or best phone," can be applied field by field.
When should merge rules differ from one duplicate search to another?
Use different merge rules when two searches find different kinds of duplicates that call for a different winning value. A search for records created twice by a web form might let the newest value win, because the newer submission is current. A search for records brought in by an import might let the older record's values win, because the import carries outdated data. A search for duplicate customers might always keep the stage and owner from the record marked as a customer. Rules shared by every search are simpler to maintain, so scope a rule to one search only when the logic really differs. In Dedupely, Custom Win and Lose Rules have an "In Duplicate Search" setting: All, one Duplicate Search, or Dedupely Intelligence. Dedupely Intelligence uses the account's Primary Record and field-level Merge Rules unless you set rules just for it.
How do merge rules differ from survivorship rules?
Merge rules and survivorship rules describe the same idea, which value survives a merge, in the words of two different fields. Survivorship is the term used in master data management, where it can cover both which record survives and which value each field keeps, often across several systems. Merge rules is the term CRM teams more often use for the field-level decisions inside one merge. Either way, the building blocks are the same: keep the primary record's value, let the newest or most complete value win, give priority to a trusted source, append multi-value fields and treat blanks as missing. In Dedupely, the record-level choice is the Primary Record, with options such as Oldest Record, Newest Record, Last Updated Record, Most Field Data or Custom. The field-level choice is Merge Rules, the automatic, repeatable version of Custom merge, where you pick each winning value by hand.
