Visible Fields
Visible fields are the fields a duplicate search shows and compares to decide whether two CRM records describe the same person, company or deal. Together they form the match key: the matching criteria that set what counts as evidence, such as an email address, a phone number, a name or a website domain.
Fields carry different weight. Strong identifiers, like an email address or a customer ID, tend to belong to one record, while weak ones, like a first name or a city, are shared by many. Choosing key fields means picking the right mix for each object, leaving out fields too unreliable to trust, and deciding how many to combine. More fields mean fewer false matches but more missed duplicates, so the fields a search compares shape what it finds as much as how strictly each one is compared.
See how Dedupely matches on the fields you choose in your CRM
What Are Visible Fields?
Visible fields are the evidence a duplicate match rests on. They go by several names, including matching criteria, key fields and match key, and choosing them answers one practical question: which fields to identify duplicates by. Many tools also show these fields side by side in the results, so a reviewer can see the values that paired two records.
Fields fall into two groups. Strong identifiers, such as an email address, a phone number, a website domain or a customer ID, tend to belong to one record, so a match on one of them is good evidence on its own. Weak identifiers, such as first name, last name, job title or city, are shared by many records. They add support to a match but rarely prove one alone.
The right fields depend on the object. For contacts, such as contacts in HubSpot, Salesforce, Nimble and Google Contacts or people in Pipedrive, email and phone lead, with names as support. For companies, such as companies in HubSpot, accounts in Salesforce or organizations in Pipedrive, website domain and company name lead, backed by a phone number or city. Deals and opportunities, in HubSpot, Pipedrive or Close, have few unique values, so the deal name is often combined with fields such as amount or close date.
Take "J. Smith, Acme, (555) 010-2000" and "John Smith, Acme Inc, 555-010-2000." A match key of first name + last name misses the pair, because "J." and "John" are different values. A match key of last name + phone, with the phone compared without its formatting, finds it.
How Visible Fields Work
The key fields in a search turn a general idea of "the same record" into criteria a tool can check. The steps are similar from one tool to the next:
- Pick the object. Fields are chosen per object, because two companies are the same for different reasons than two people or two deals are.
- Choose the fields. Start from the strongest identifiers the object has, then add weaker fields as support.
- Set how each field is compared. Each field gets a method that fits how its values vary: exact for email addresses, a method that ignores formatting for phone numbers, a typo-tolerant or sound-alike method for names.
- Combine the fields. In rule-based matching, each field in a rule has to meet its criteria, so every field added makes the rule stricter. In score-based matching, each field carries a weight, and records pair when their total score passes a threshold.
- Leave out unreliable fields. A field that's often blank, holds placeholder values like "N/A" or is entered inconsistently is left out of the match, or the records with those values are filtered out first, so it can't block real matches or create false ones.
The number of fields sets the balance. One field, especially a weak one, pairs records that only happen to share a value. Each field added cuts those false matches, but it's also one more value that has to agree, so duplicates with a blank or outdated value get missed. A few fields, anchored by one strong identifier, often sit in the middle.
Why Visible Fields Matter for CRM Teams
The fields a search compares decide which records end up merged together. A match key built on a weak field, such as first name + last name alone, pairs different people who share a name. If that set is merged, two customers' histories, owners and contact details end up on one record, and in many systems a merge is hard or impossible to reverse. Placeholder values do the same kind of damage when the field that holds them stays in the match.
A match key that's too strict causes the opposite problem. Duplicates that differ on one compared field stay in the CRM: they keep inflating contact counts and pipeline totals, split activity history across records and put the same customer in front of two reps. In CRMs that bill by record count, each one is also a record the company pays for twice.
Clear, deliberate key fields also make the results easier to trust and repeat. When the match key for each object is written down, anyone on the team can see why two records were paired, the same records give the same results on every run, and the criteria built on strong identifiers can run on a schedule as new records arrive from forms, imports and syncs. Criteria built on weaker fields can stay with a person for review.
Getting Started With Visible Fields
Deciding which fields to dedupe on starts with the strongest identifier each object has. Check how complete it is before building on it. A field that's blank on half the records can only match the other half, and one filled with placeholders or mixed formats can pair records that aren't the same. A quick look at a sample shows how often each field is filled in and how consistent its values are.
Build the match key from a few fields: one strong identifier plus one or two supporting fields. Run it and review a sample of the results before merging anything. If it pairs records that aren't duplicates, add a supporting field or compare one more strictly. If it misses duplicates you can see, find the field that breaks the pair, then loosen it or leave it out.
Keep separate criteria for separate patterns, such as one built on email and another on name + phone. Change one field at a time, so it's clear which change found new duplicates and which one let false matches in.
In Dedupely, a Duplicate Search's Visible Fields carry out this approach: each one gets its own Match Option, so you can build the match key from the 2 to 4 key fields the KB recommends. One Duplicate Search can also hold several match groups, to combine different criteria.
Key Takeaways: Visible Fields
Visible fields are the fields a duplicate search shows and compares, often called the match key or key fields. Strong identifiers, such as email, phone, website domain or a customer ID, anchor the match, while weaker fields like names and cities support it. The right fields depend on the object: contacts lean on email and phone, companies on domain and name, and deals on the deal name plus amount or close date. More fields mean fewer false matches and more missed duplicates, so a few well-chosen fields, with unreliable ones left out, often work best. In Dedupely, each of a Duplicate Search's Visible Fields gets its own Match Option, and the KB recommends combining 2 to 4 key fields. Two Enhancements apply to the whole match: Cross-field matching finds misplaced values in other fields used in the match, and Typo allowance keeps small differences from blocking it.
Frequently Asked Questions About Visible Fields
Which data attributes are most useful when matching customer records?
Unique contact details are the most useful: email address, phone number and any customer or account ID. Each one tends to belong to a single person, so a match on one of them is strong evidence, and website domain plays the same role for companies. Names, job titles, cities and company names help as support, but many records share them, so they work best combined with a stronger attribute. Postal addresses fall in between, because they're useful but often entered in different formats. Before relying on an attribute, check how often it's filled in and how consistent it is, since a strong field that's blank on most records finds little. In Dedupely, each Visible Field in a Duplicate Search gets its own Match Option to fit how its values vary. Exact ignores capitalization, Similar compares phone numbers on their last seven digits without formatting or country codes, Fuzzy catches names that sound alike, and Domain Root compares the core domain of an email or website.
How many visible fields should a duplicate search compare?
A few, with at least one strong identifier among them. One field on its own, especially a name, pairs records that just share a value. Each field you add cuts those false matches, but it's also one more value that has to agree, so duplicates with a blank, outdated or mistyped value start to slip through. A combination such as first name + last name + email, or company name + website domain, often gives a good balance. If a combination finds too little, look for the field that breaks the pairs before adding or removing others. Dedupely's KB recommends combining 2 to 4 key fields in a Duplicate Search, and if a search compares three fields, all three must meet their criteria to flag a duplicate. One Duplicate Search can also hold several match groups, to combine different criteria, and you can clone a search to try a new combination without changing the active one.
When should you leave a field out of the match?
Leave a field out when its values can't be trusted to mean the same thing across records. That includes fields that are often blank, fields filled with placeholder values such as "N/A" or "none," fields that hold shared values like a main office number or an info@ address, and fields entered in so many formats that they block real matches. Keeping such a field in the match either splits real duplicates apart or ties unrelated records together. Leaving it out, or filtering out the records with bad values, lets the stronger fields do the work, and the field can come back once its data is cleaned up. In Dedupely, filters limit which records a Duplicate Search evaluates, so records with bad values can stay out of the results. On each field, the "Send incorrect formats to manual review" checkbox, off by default, sends invalid values, such as an email in the wrong format, and filler values like blank or N/A to Manual Review automatically. Safety Settings, on by default, also hold back matches built on placeholder data.
Which fields should you dedupe on for companies and deals?
For companies, dedupe on website domain and company name, backed by a phone number or city. A shared domain is strong evidence, while company names vary with legal suffixes like Inc. or Ltd. and with word order, so they compare best word by word with those suffixes ignored. That holds for companies in HubSpot, accounts in Salesforce and organizations in Pipedrive alike. Deals and opportunities have fewer unique values, so combine the deal name with fields such as amount or close date, and review a sample before merging, because two real deals with the same customer can look alike. Keep each object's criteria separate, since a company and a deal are the same for different reasons. In Dedupely, Domain Root matches the core domain of an email or URL and ignores www, .com and country variants. Similar Words compares the shared words in a company name, and up to 50 Ignored Terms per field, such as Inc., LLC and Ltd., keep suffixes out of the comparison.
Why does adding a field to the match key make a search miss duplicates?
In rule-based matching, each field in the match key has to meet its criteria, so every field added is one more value that has to agree. Two records for the same person can share an email and a last name but differ on phone because one number is outdated, or on job title because one record is newer. Add phone or title to the match key and the pair no longer matches. Blank values cause the same problem. To find the cause, compare a pair you know is a duplicate field by field, then loosen that field's method, take it out of the match or give it criteria of its own. In Dedupely, if a search compares three fields, all three must meet their criteria. Two Enhancements apply to the whole match: Typo allowance keeps small differences from blocking a match when stricter matching is used, and Cross-field matching finds misplaced values in other fields used in the match. After changing fields or Match Options, click Scan to update the results.
