CRM Objects
CRM objects are the record types a CRM uses to organize its data, such as contacts, companies, deals, leads and tickets. Each object holds one kind of thing, has its own set of fields, and links to records in other objects, so a contact can belong to a company and take part in a deal.
Most CRMs come with standard objects, and many also support custom objects for data the standard ones don't fit, such as subscriptions, properties or locations. Duplicates can appear in every object, standard or custom. Because each object describes something different, the fields that show two records are the same also differ: an email address for a contact, a website domain for a company. That's why deduplication is often done one object at a time, with matching fields chosen for each one and merges that stay within the object.
See how Dedupely finds duplicates object by object in your CRM
What Are CRM Objects?
CRM objects are the building blocks of a CRM's data model. Each object is a category of record with its own fields: a contact has a name, an email address and a phone number, a company has a name, a domain and an address, and a deal has a name, an amount and a stage. Records in one object are linked to records in others, and those links are what turn separate records into a full customer view.
CRMs name and group their objects in different ways. HubSpot's objects include contacts, companies, deals, leads, tickets and custom objects. Salesforce's include accounts, contacts, leads and custom objects, Pipedrive's include people, organizations, deals, leads and products, and Close's include leads, contacts and opportunities. Nimble and Google Contacts center on contacts. The same idea can carry different names: a company in HubSpot is an account in Salesforce and an organization in Pipedrive.
Standard objects are the ones a CRM provides out of the box. Custom objects are ones a team creates for data that doesn't fit them, with fields the team defines. Custom objects can hold duplicates just like standard ones, often from imports or integrations that sync records in.
A simple example: Acme exists twice in the companies object, as "Acme Inc" with acme.com and "ACME" with www.acme.com. J. Smith, who works there, exists twice in the contacts object. Cleaning this up takes two merges, one in each object, and the contact merge is checked against the company records it links to.
How CRM Objects Work
Every record in a CRM belongs to exactly one object, and that object decides which fields the record has and which other records it can link to. Deduplication follows the same structure, roughly in these steps:
- Pick the object. A merge combines records of the same type, so duplicates are found among contacts, among companies, and so on. A lead and a contact are separate objects in many CRMs, even when they describe the same person.
- Choose fields that suit it. Contacts often match on email address, name and phone. Companies match better on website domain and company name, where legal suffixes and "www" create variations. Deals might match on deal name together with the linked company, and custom objects on whatever field identifies each record, such as an ID or an address.
- Group the matches. Records that match are grouped into duplicate sets within that object.
- Merge within the object. Each set becomes one record of the same type. Its associations to other objects, such as linked deals or tickets, move to the surviving record.
- Repeat for the next object. Linked objects are often cleaned one after the other, so merged contacts don't end up pointing to two versions of one company.
Some objects carry their own limits. Pipedrive's built-in merge, for example, doesn't cover products, and archived deals and leads in Pipedrive can't be merged.
Why CRM Objects Matter for CRM Teams
Duplicates in each object distort a different part of the business. Duplicate contacts inflate audience counts and send the same email twice. Duplicate companies split revenue, activity and ownership across two accounts, so account-based reports show a customer as two smaller ones. Duplicate deals overstate the pipeline and the forecast built on it. Duplicate tickets make one support issue look like several and can put two agents on the same request.
Because objects are linked, a duplicate in one often spreads into others. A contact tied to a duplicate company appears under the wrong account, and a deal tied to a duplicate contact can drop out of a rep's view. Cleaning only contacts leaves those links pointing to duplicate companies, so reports that follow associations from one object to the next stay off. Routing and segments that rely on a record's company or deal links can also send a customer to the wrong team or leave it out of a list.
Custom objects carry the same risk, often with less attention. They tend to be filled by integrations and imports, and teams don't always check them with the care they give contacts. In CRMs that bill by contact or record count, each duplicate is also a record the company pays for more than once, whichever object it sits in.
Getting Started With CRM Objects
Start by listing the objects your CRM uses, including custom ones, and roughly how many records each holds. Note which objects feed the reports and workflows the business relies on, such as companies for revenue or deals for the forecast. Those are good candidates to clean first.
For each object, choose matching fields that fit what it describes. Email and name suit contacts, domain and company name suit companies, and a custom object needs whichever field identifies its records. Check the first results for each object before merging anything, because fields that work well on one object can pair unrelated records in another.
Plan the order around links. Cleaning companies and contacts close together keeps associations pointing to a single version of each account, and deals or tickets can follow once the records they link to are clean. Then keep each object in the regular checks, since new duplicates can arrive in any of them.
In Dedupely, matching and merging stay within one object, so contacts, companies, deals, leads or custom objects each get their own Duplicate Searches with the fields and Match Options that suit them. Merge Rules are also set per object, and activities and associations are preserved when that object's duplicates merge.
Key Takeaways: CRM Objects
CRM objects are the record types a CRM stores, such as contacts, companies, deals, leads, tickets and custom objects. Each object has its own fields and links to records in others, and duplicates can appear in every one of them. Because objects describe different things, each needs its own matching fields, and merges happen within one object at a time. In Dedupely, matching and merging stay within one object, so a Lead can't be merged with a Contact, and Merge Rules, Safety Settings and Merge History are set or kept per object. Activities and associations are preserved on merge. For each object, Auto Match notifies you when new matches reach a count you set, and Auto Merge merges new duplicates on a schedule.
Frequently Asked Questions About CRM Objects
Which CRM objects can have duplicates?
Every CRM object can have duplicates, from contacts and companies to deals, leads, tickets, products and custom objects. Contacts are the most visible, because forms, imports and sales tools create new ones often, but companies are close behind: the same business can arrive as "Acme Inc" and "ACME" from two sources. Deals duplicate when two reps open one for the same opportunity, tickets when one issue comes in through two channels, and custom objects when an integration syncs the same item twice. Which objects you can clean depends on the CRM and the tool. In Dedupely, the objects you can deduplicate depend on the CRM: Contacts, Companies, Deals, Leads, Tickets and Custom Objects in HubSpot; Accounts, Contacts, Leads and Custom Objects in Salesforce; People, Organizations, Deals, Leads and Products in Pipedrive; Leads, Contacts and Opportunities in Close; and Contacts in Nimble and Google Contacts. Each object syncs as a whole, and objects can be turned on or off.
Can you deduplicate custom objects in a CRM such as HubSpot or Salesforce?
Yes, custom objects can be deduplicated the same way as standard ones: by matching their records on the fields that identify them and merging the sets. The main difference is that a custom object's fields are defined by your team, so there's no standard field like email to rely on. Pick the field or combination of fields that should be unique, such as an external ID, a serial number or a name with an address, and check the first results before merging. Custom objects are often filled by integrations, so it also helps to find which source creates the duplicates. Whether a CRM's built-in tools cover custom objects varies, so check what yours supports. In Dedupely, Custom Objects can be synced and deduplicated in HubSpot and Salesforce, with their own Duplicate Searches. Synced custom fields can also be used in filters, and Merge Rules decide which values each merged record keeps.
Can you merge records from two different objects, such as a lead and a contact?
No, merging combines duplicate records within one object, so leads merge with leads and contacts with contacts. A lead and a contact are separate objects in many CRMs, with different fields and different places in the sales process, and Salesforce, for example, doesn't allow a Lead to merge into a Contact. When the same person exists in both, moving the lead into the contact object is a separate step from deduplication, and the CRM's own documentation explains how it works there. The same applies to other pairs, such as a company and a custom object that describes a location. Once records sit in one object, any duplicates there can be found and merged. In Dedupely, matching and merging work within one object, so a Lead can't be matched or merged with a Contact. You can run separate Duplicate Searches on leads and on contacts in CRMs that have both objects, such as HubSpot, Salesforce or Close.
Why do companies need different matching than contacts?
Because the fields that show two companies are the same aren't the ones that work for people. Contacts often match on an email address, which belongs to one person, together with a name or phone number. Companies rarely have a field that unique. Their names vary with legal suffixes, punctuation and abbreviations, such as "Acme Inc," "Acme, Inc." and "ACME," and their websites appear with and without "www" or with country domains. Matching companies on website domain, or on the domain part of their email addresses, plus a cleaned-up company name, often finds duplicates a name-only match misses. Many contacts at one company also share a domain, so domain matching suits companies far better than contacts. In Dedupely, companies and contacts get separate Duplicate Searches with their own fields, since matching stays within one object. Domain Root matches the core domain of an email or website and ignores www, .com and country variants, and Ignored Terms can leave out words such as "Inc" when names are compared.
How do associations link CRM objects when duplicates merge?
Associations connect records across objects, and a merge moves them from each duplicate to the record that survives. A contact can link to a company, deals, tickets and activity, and each duplicate often holds part of that. When two contacts merge, the deals and tickets from both end up on one contact, and links they share are kept once. The details vary by CRM: HubSpot moves associated contacts, deals and timeline history, while Salesforce reparents opportunities, tasks, cases, notes and custom related lists. If the linked records are duplicates too, such as one company entered twice, they need their own merge in their own object. In Dedupely, all activities, such as notes, calls and tasks, and all associations, such as linked companies, deals and contacts, are preserved on merge. For HubSpot's cap on associations per record, Merge choices in Safety Settings set a standing answer: Always ask, Merge and keep the associations that fit, or Skip.
