# Edge cases in CRM deduplication a person should decide | Dedupely > Shared inboxes, families, subsidiaries, partners who buy and customers who come back need a person to decide. See the question that settles each case. - URL: https://dedupe.ly/blog/crm-deduplication-edge-cases - Section: blog - Published: 2026-10-22 - Site index: https://dedupe.ly/llms.txt - Any page: append `.md` to its URL for this plain-text form --- [Blog](https://dedupe.ly/blog) Duplicates ## Edge cases in CRM deduplication a person should decide By [Gaby Salinas](https://www.linkedin.com/in/gbyslns) Updated October 22, 2026 # min read 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](https://dedupe.ly/blog/related-records-not-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. Note Merging a returning customer's records can change churn and reactivation reports, since one customer no longer appears as two. Agree with whoever owns those reports 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](https://dedupe.ly/blog/one-person-several-roles-duplicate) or [a contact who changed jobs](https://dedupe.ly/blog/contact-job-change-duplicates). ### 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. [Sort your edge cases from your duplicates](https://v2.app.dedupe.ly/signup) ### 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. Behind the article ### Gaby Salinas Marketing Assistant at Dedupely Gaby Salinas came to CRM data from marketing and advertising, so she looks at duplicates from two sides: the match and merge logic behind them, and what they do to the people using the CRM, like the rep who calls a customer twice, the admin who gets blamed and the cleanup nobody wants to start. As Marketing Assistant at Dedupely, she follows how RevOps teams, end users, consultants and technical teams actually work with their data: the records they stop trusting, the workarounds they build and the moment they finally decide to clean up. What she finds shapes most of what Dedupely publishes. [Connect with Gaby on LinkedIn](https://www.linkedin.com/in/gbyslns) ### Contact us We’d be happy to help you get this set up. #### Write us a message We probably know the answer to your question already help@dedupe.ly Email copied to your clipboard! [Book a Zoom Whether you’re getting started or getting intense. Get in touch! Book a zoom](https://meetings.dedupe.ly/meetings/gaby-salinas/dedupely-zoom-scheduler) ### Discover Related Blog Posts Stay updated with our latest articles and insights. [Duplicates How to handle related records that look like duplicates Subsidiaries, branches, shared inboxes and families can look like duplicates. Define why they aren't, then reject the match so it stops coming back. Gaby Salinas October 28, 2026](https://dedupe.ly/blog/related-records-not-duplicates) [CRM Organization Is a person with several roles a duplicate record? A customer who's also a job applicant, or an advisor at two companies: one record or two? How to decide, case by case, and keep intended pairs apart. Gaby Salinas October 19, 2026](https://dedupe.ly/blog/one-person-several-roles-duplicate) [CRM Organization When a contact changes jobs, is it a duplicate? When a contact changes jobs, merging the old and new records keeps the context. Account-based and person-based teams differ in which values win. Gaby Salinas October 19, 2026](https://dedupe.ly/blog/contact-job-change-duplicates) ### Get started for free 20 free trial merges and as much free support as you need to get your duplicates under control. [Talk to sales](https://meetings.dedupe.ly/meetings/gaby-salinas/talk-to-sales)[Try for free](https://v2.app.dedupe.ly/signup) [Or sign up with Google](https://v2.app.dedupe.ly/signup/google) Running CRM cleanup for clients? [See the Partner Program](https://dedupe.ly/become-a-partner) Skip to content