TL;DR
- Some duplicate sets depend on how your business works, so a person should decide them.
- Shared inboxes, family members and subsidiaries often match without being duplicates.
- A partner that's also a customer may need one record or two, depending on your setup.
- A customer who cancelled and came back is usually one person with two records.
- Dedupely lets you send edge cases to review and reject sets you're certain aren't duplicates.
Many duplicates are easy to call. Two contacts with the same email and name are the same person, and a rule can merge them.
A few sets look just as clear in the data and still aren't. They match on every field you search by, but whether they're duplicates depends on how your business sells, bills and serves people. No rule knows that, so a person has to decide.
In this post, you'll see five edge cases that come up often and the question that settles each one. You'll also see how to route them to the right person and how to keep the same set from coming back.
Why some sets need a person
A duplicate search compares fields. Edge cases share those fields for a reason outside the data, like a shared address, a family, a company structure or a customer's history.
What counts as a duplicate is case by case. What one team considers a duplicate, another may not. Two subsidiaries can be one account for a company that sells to the group and two for one that sells to each.
That's why these sets shouldn't go through bulk or automatic merges. They need someone who knows the business to look at each one.
Five edge cases and the question that decides each
Shared inboxes
Addresses like info@, sales@ or support@ belong to a team. Several people can fill in forms with the same address, so a search on email groups them.
The deciding question: is there one person behind the address, or several? If several real people used it, they're separate contacts. If one person entered the shared address twice, the records are duplicates.
Family members
In consumer businesses, a household often shares one email, phone or address. A parent and a child, or two partners, can each be a separate customer.
The deciding question: do you serve each person, or the household? A business that bills the household may want one record. One that serves each person, like a school or a clinic, needs separate records even with the same email.
A parent company and its subsidiary
A subsidiary often shares a brand, a domain and an email format with its parent. Many CRMs hold them as separate company records, each with its own contacts and deals.
The deciding question: do you sell to and bill each one separately? If yes, keep them apart and link them as parent and child. If your company treats the group as one customer, merging may be right.
Our post on related records that look like duplicates covers subsidiaries and branches in more depth.
A partner that's also a customer
A company can resell or refer your product and also use it. It may then exist twice: once for the partner team and once for sales or customer success.
The deciding question: are the two records separate by design, or by accident? Some teams keep a partner record and a customer record on purpose, each with its own owner, deals and reports. Others want one company record that shows both relationships, usually through a field like company type.
- If they're separate by design, reject the match and leave both.
- If they're separate by accident, merge them, keep both relationship types and agree on the owner first.
A subscription customer who left and came back
A customer buys a subscription, cancels and returns months later. It happens to us too. Signing up again can create a new contact, sometimes with a new email, while the old record still says "former customer."
The deciding question: is it the same person, and does your reporting need both records? It's usually one person, so one record with the full history is easier for everyone. Before merging, check three things:
- Lifecycle stage: the current status, like active customer, should win over the old one.
- Dates: keep the first purchase date, so the customer's full tenure stays visible.
- Billing links: if a billing or subscription tool syncs with the CRM, check how it handles a merge before you merge.
Edge cases at a glance
| Case | The question that decides it | Often one record when… | Often separate when… |
|---|---|---|---|
| Shared inbox | One person or several? | One person entered it twice | Several people used it |
| Family members | Do you serve the person or the household? | You bill the household | You serve each person |
| Parent and subsidiary | Do you sell to and bill each one? | You sell to the group | Each has its own contract |
| Partner and customer | Separate by design or by accident? | It's an accident | Each team keeps its own record on purpose |
| Returning subscriber | Same person? Does reporting need both? | It's the same person | Your reports require separate records |
Other cases follow the same logic, like one person with several roles or a contact who changed jobs.
How to handle edge cases in a cleanup
Send them to the person who knows
Route each edge case to someone who knows the records. That's the account owner for a subsidiary, the partner manager for a partner or customer success for a returning customer. Ask them to decide, then merge or keep the records apart.
Reject the match when you're certain
Once you're certain a set isn't a duplicate, reject it. A rejected set doesn't come back in later searches, so nobody has to decide the same case twice. If you're not certain, leave it in review instead.
Narrow the search when a case repeats
If a whole type of edge case keeps matching, change the search instead of deciding each set. Leave shared addresses like info@ out of email matches, or add a field like city or record type that tells the records apart.
Write the decisions down
Keep a short list of the cases your team has decided and why. "Subsidiaries with their own contract stay separate" saves the next person from reopening the question.
How Dedupely helps you decide edge cases one by one
In Dedupely, you can send any set to review, where it waits until someone merges or removes it. When you're certain a set isn't a duplicate, you reject it, and it stays out of current and future searches.
Filters let you leave values like shared inboxes out of a search. By default, risky matches like sets of more than 20 records are excluded.
A person for the cases a rule can't see
Edge cases match on the fields a search uses, but the answer sits in how your business works. Shared inboxes, families, subsidiaries, partners who buy and customers who return each turn on one question about that.
Ask the question, let the person who knows decide and reject the sets you're certain about. Over time, the list of decisions grows, and fewer sets need a person at all.
Frequently asked questions
Which duplicates should not be merged automatically?
Sets that depend on how your business works: shared inboxes, family members, parent companies and subsidiaries, partners that are also customers and returning customers. They often match on email, name or domain without being duplicates. Send them to someone who knows the records before anything merges.
Is a returning customer a duplicate record?
Usually, yes, when it's the same person who signed up again, and merging keeps the full history on one record. Let the current lifecycle stage win, keep the first purchase date and check how any billing tool synced to the CRM handles merges. Agree on churn reporting first.
Should a partner and a customer be the same record in a CRM?
It depends on whether the two records are separate by design. Some teams keep a partner record and a customer record on purpose, while others use one company record with a type field. If the split is accidental, merge the records and keep both relationship types.
Are contacts with the same email always duplicates?
No. Shared inboxes like info@ and household emails can belong to several people, so check who is behind the address. If several real people used it, keep separate contacts and reject the match; if one person entered it twice, merge the records.
When should you reject a duplicate match?
Only when you're certain the records aren't duplicates, like two subsidiaries with separate contracts or two family members you serve separately. A rejected match doesn't come back in later searches. If you're unsure, send the set to someone who knows the records instead of rejecting it.
Or sign up with Google
HubSpot Marketplace 
