Primary Record
A primary record is the record that's kept when a set of duplicate records in a CRM is merged. Also called the master record, surviving record or winning record, it's the record the others merge into, and it often keeps its record ID, URL, owner and creation date.
Choosing the primary record is a record-level decision. It sets which record keeps its identity in the CRM, so integrations, saved links, reports and owners keep pointing at the right place. Which value each field keeps is a separate, field-level decision made by merge rules, so the primary record doesn't have to keep all of its own values. Common ways to pick it are the oldest record, the newest, the last updated, the most complete, or a rule based on a field such as lifecycle stage or owner.
See how Dedupely picks the record each merge keeps in your CRM
What Is a Primary Record?
A primary record is the anchor of a merge: the one record in a duplicate set that stays in the CRM while the others merge into it. Its identity carries on, which in many CRMs means its record ID, its URL, its owner and its creation date. Not every CRM works that way. HubSpot, for example, gives the merged record a new ID, and the old IDs redirect to it.
A simple example: two company records for Acme. Record A was created three years ago, is owned by J. Smith, and its ID is stored in an invoicing system. Record B came in last week from a form and has a newer phone number. With Record A as the primary record, Acme keeps the ID, owner and creation date the business already uses, and a field rule can still bring in Record B's phone number. With Record B as primary, the ID the invoicing system knows belongs to a record that's merged away.
Every object that's deduplicated has a primary record in each merge: contacts and companies in HubSpot, accounts and leads in Salesforce, people and organizations in Pipedrive, leads in Close, and contacts in Nimble and Google Contacts.
There are a few common ways to pick it. The oldest record often has the longest history and the ID other systems already use. The newest record reflects the latest form fill or import. The last updated record is the one someone worked on most recently. The most complete record has the fewest gaps to fill. A rule-based choice, such as the record with a customer stage or a named owner, puts a team's own priorities first.
How a Primary Record Works
Picking a primary record follows the same few steps, whatever tool or CRM does the merge:
- Set a rule for each object. Contacts, companies and deals change in different ways, so each object can have its own rule. A rule that compares dates, such as oldest, newest or last updated, depends on the created and modified dates in the CRM being accurate.
- Apply the rule to each duplicate set. The records in the set are compared on that rule, and one of them becomes the primary record. With a rule based on a field value, such as lead status, it's worth checking the sets where several records meet the condition, or none do.
- Decide the field values separately. Merge rules then decide which value each field keeps. The primary record's value is often the starting point, and other rules can bring in a newer, longer or filled-in value from the other records.
- Merge the other records into it. Activity, notes and associations from the other records move onto the primary record, and those records are removed. Some CRMs hold removed records for a while: Salesforce, for example, keeps the primary record's ID and sends the others to the Recycle Bin for 15 days.
- Check what the merged record kept. In many CRMs, the ID, owner and creation date on the merged record come from the primary record. In HubSpot, the merged record gets a new ID instead, so anything that stored an old ID relies on the redirect.
Why a Primary Record Matters for CRM Teams
The primary record decides which identity a customer keeps after a cleanup. Integrations such as billing, support and marketing tools often store a CRM record ID to keep their data in step. When the record with that ID is merged away, the link can break or point to a record that no longer exists, unless the CRM redirects old IDs. Bookmarks and links saved in emails, documents and other records depend on the same ID.
Reporting follows the primary record too. The creation date often feeds reports on lead age, time to close and new records by month, so keeping a newer record as primary can make a long-time customer look like a new lead. Ownership works the same way: if the owner comes from the primary record, a merge can move an account to a different rep or leave it with no owner at all.
Field values can be fixed with field rules, but the record's identity can't be swapped after the merge. Because many merges are hard to reverse, a wrong primary record tends to stay wrong for a long time. Choosing the master record on purpose, object by object, keeps each customer in the place the rest of the business already looks for it.
Getting Started With a Primary Record
Start by finding out what depends on your record IDs. List the integrations and tools that store a CRM ID, and check whether your CRM keeps the primary record's ID on a merge or creates a new one. When other systems point at existing IDs, the oldest record is often the safest primary record, because it's the one they already know.
Then choose a rule for each object. Contacts change jobs and email addresses, so the last updated or most complete record can make sense there. Companies and accounts are often tied to contracts and billing, which favors the oldest. Where one stage or owner should always win, such as a customer over a lead, a rule based on that field puts it first.
Keep the record choice and the field choices apart. Pick the primary record for its identity, then set field rules so better values from the other records still reach the merged record. Preview a few merged sets before merging in bulk, and check the ID, owner and creation date that remain.
In Dedupely, the Primary Record is set in Merge Rules as the Oldest Record, Newest Record, Last Updated Record, Most Field Data or a Custom rule on the fields you choose, such as lead stage. Field-level Merge Rules then decide which value each field keeps, and a preview shows the merged result, with the primary record labeled, before anything changes in the CRM.
Key Takeaways: Primary Record
A primary record, or master record, is the record that's kept when duplicates merge, and the other records merge into it. It often keeps the record ID, URL, owner and creation date that integrations, links, reports and teams depend on, so it's chosen as a record-level decision, apart from which value each field keeps. Common choices are the oldest, newest, last updated or most complete record, or a rule based on a field. In Dedupely, the Primary Record can be the Oldest Record, Newest Record, Last Updated Record, Most Field Data or Custom, and field-level Merge Rules decide each field's value. All activities and associations are preserved on the record that's kept, and Merge History records each merge with its original records.
Frequently Asked Questions About Primary Records
Which record is kept as the master record when you merge duplicates in a CRM such as HubSpot or Salesforce?
The primary record is kept, and which record that is depends on the rule the merge follows. In a native merge, the CRM's own logic decides, and the details vary. Salesforce, for example, keeps the primary record's ID and sends the other records to the Recycle Bin for 15 days, while HubSpot gives the merged record a new ID and redirects the old ones. Outside the native tools, the choice is often set as a rule: the oldest record, the newest, the last updated, the most complete, or a record chosen by a field value. Whichever record is kept, field rules can still pull better values from the others. In Dedupely, the Primary Record can be the Oldest Record, Newest Record, Last Updated Record, Most Field Data or Custom. Without Merge Rules, Dedupely follows the CRM's own merge logic, which often keeps the oldest Record ID, and HubSpot creates a new ID on every merge.
What's the difference between a master record and a surviving record?
There's no difference: master record, surviving record, winning record and primary record are different names for the same thing. Each one describes the record that stays in the CRM when a duplicate set is merged, with the other records merged into it. Tools and CRMs simply use different wording. A related but broader idea is the golden record, a term from master data management for the single best version of a customer, often built from several systems. A primary record is narrower: it's the specific record that's kept in one CRM, whatever values end up in its fields. That's why the record choice and the field choices are best treated as two decisions. In Dedupely, the Primary Record decides which record is kept, and field-level Merge Rules decide which value each field keeps, with options such as Primary, Append for the CRM's own multi-value fields, and Custom rules.
Does the record ID change after duplicate records are merged?
It depends on the CRM. Some CRMs keep the primary record's ID, so anything that stored it keeps working. Salesforce, for example, keeps the primary record's ID and sends the other records to the Recycle Bin for 15 days. Others create a new ID: HubSpot gives the merged record a new ID on every merge, and the old IDs redirect to it. Either way, the IDs of the records that aren't kept stop pointing at a live record of their own. Before merging, list the integrations, reports and links that store record IDs, check how your CRM handles them, and pick a primary record that keeps the ID those systems use. Without Merge Rules, Dedupely follows the CRM's own merge logic, which often keeps the oldest Record ID. HubSpot is the exception, since HubSpot itself creates a new ID on every merge. Merge History links each merge to the record in the CRM.
How do you choose the primary record for companies vs contacts?
Choose for each object separately, based on what depends on its records. Companies and accounts are often tied to contracts, invoices and other systems by their ID, and they tend to build up history over years, so the oldest record is often the safest primary record. Contacts change jobs, email addresses and phone numbers more often, so the last updated or most complete record can suit them better, as long as field rules keep any value worth keeping from the older record. Deals and leads may follow a stage instead, such as keeping the record that's furthest along. Whatever the rule, preview a few merged sets per object and check the ID, owner and creation date that remain. In Dedupely, Merge Rules are set per object, so companies can keep the Oldest Record while contacts use the Last Updated Record or Most Field Data. Dedupely can't merge across objects, such as a Lead with a Contact.
Can the primary record be chosen by a field such as lead status?
Yes. A rule-based primary record picks the record whose field meets a condition, such as the one with a customer lead status or a named owner, instead of relying on dates. It suits teams with clear priorities, for example keeping the record a sales rep is working over one created by a form. Field-based rules need a little more care than date-based ones: check the sets where several records meet the condition and the sets where none do, and order the conditions so the most important one wins. In Dedupely, a Custom Primary Record is built from Win Rules and Lose Rules on the fields you choose, such as phone number or lead stage. Each rule sets a field, an operator and a term, and it can apply to all Duplicate Searches, one Duplicate Search or Dedupely Intelligence. Lose Rules run before Win Rules, and Win Rules run from top to bottom.
