TL;DR
- One person can hold several roles in one CRM, like customer and job applicant.
- Whether two records for one person are duplicates is case by case.
- One record fits when the same team works every role and reports count people.
- Separate records fit when roles need different owners, access, consent or processes.
- Dedupely merges the records that are one person and keeps intended role records out of merges.
A duplicate search turns up two records with the same name and phone number. One is a customer, and the other applied for a job last month. Same person, no doubt about it.
The harder question is whether they should be one record. Merging them could put an applicant's details in front of a sales rep, or put a customer into a hiring workflow. Keeping them apart means the CRM knows the person twice.
In this post, you'll see common cases of one person with several roles and the questions that decide one record or two. You'll also see how to keep intended pairs out of your cleanups.
What "several roles" looks like in a CRM
A role is the reason a person is in your CRM. Many people have one. Some have two or more at the same time, and each role may have arrived through a different door.
| Case | How the second record appears | What usually differs |
|---|---|---|
| Customer and job applicant | A hiring form or careers page creates a new contact | Team, owner, who should see the record |
| Advisor or consultant at two companies | Each company's deal or import adds the person with that company's email | Email, company, owner |
| Customer who is also a partner or reseller contact | The partner team adds the person under the partner company | Company, pipeline, lifecycle stage |
| Employee who is also a customer | The person buys with a personal email | Email, lifecycle stage, internal status |
| Donor who is also a volunteer or member | A separate sign-up form or event list | Program, consent, communication preferences |
A contact who changes jobs holds one role after another. Here, both roles are current.
Why the answer is case by case
What counts as a duplicate is case by case, and what one team considers a duplicate, another may not. Two records for one person are a problem for a team that counts people. For a team that tracks relationships, they can be exactly right.
The same pair can also change status over time. A customer who applies for a job and gets hired becomes an employee, and the right answer for the records may change with it.
So the first decision is what each role means to your team, before any matching starts.
Questions that decide one record or two
Answer these for each case before you merge anything. If the answers point different ways, keep the records apart until your team agrees.
Does the same team work both roles?
When sales handles a customer and the same person as a partner contact, one record gives every rep the full picture. When sales handles the customer and HR handles the applicant, the two roles rarely need to meet.
Do the roles need different access or consent?
Applicant data, internal employee details and donor records can carry rules about who sees them. A merge puts everything on one record that everyone with access to that record can read. If a role's data shouldn't reach another team, keep it on its own record.
Consent works the same way. A person may agree to marketing as a customer and not as an applicant. One record can blur which consent belongs to which role.
Do your reports count people or relationships?
A report on unique customers wants one record per person. A report on hiring pipelines, partner programs or volunteer hours wants each role counted where it belongs. Check which reports read the object before you decide.
Do processes act on the role?
Workflows, sequences and routing rules often trigger on a field like lifecycle stage or record type. One record with two roles can trigger both sets, so a customer lands in an applicant follow-up, or an applicant in a sales sequence.
When one record is the right answer
One record works when the roles share a team, the data can be seen by everyone who works the record, and reports count people. Merge the records, then show the extra role some other way.
- A role field: a multi-select property such as "Partner" or "Volunteer" keeps the role visible for lists and reports.
- Links to several companies: some CRMs let one contact be associated with more than one company, with one marked as primary. An advisor at one company and an employee at another stays one person.
- Labels on each link: some CRMs also let you describe each relationship, like "Advisor" or "Billing contact", without a second record.
Before merging, decide which value wins in fields that differ between roles, like email, owner and lifecycle stage. A person who is a customer and a partner contact may need the customer's owner and the most advanced stage.
As of October 2026, from HubSpot's knowledge base: Associate records, and Salesforce Help: Contacts to multiple accounts.
When separate records are the right answer
Separate records fit when the roles need different owners, different access or different processes. Applicants and customers can fall on either side, depending on whether hiring and selling share a team and a workflow.
They also fit when each role belongs to a different business relationship. A consultant who works with two of your client companies may use two work emails. A record for each lets each account team see only its own conversations.
The same logic applies to related records that look like duplicates, like branches and subsidiaries.
If a role lives in its own object, like a separate candidate object, the two records may never meet in a duplicate search. That separation can be the simplest answer.
How to keep intended pairs out of a cleanup
Once you've decided that some pairs stay separate, protect that decision. Otherwise the next broad search, or the next person running it, merges them.
Start with the obvious duplicates
Begin with exact matches on the field that identifies each record, like email. These are rarely two roles, since separate roles often come with separate emails. Leave name and phone matches across roles for later.
Use a field to separate roles
A record type, role or source field lets you narrow a search to one role at a time. Searching customers against customers keeps applicants out of the result without rejecting each pair by hand.
Reject a match only when you're certain
When a pair is one person in two roles you mean to keep, reject the match and write down why. A rejected match usually stays out of future searches, so only reject when you're sure. When you aren't, send the set to review and ask the team that owns the role.
Write the rule down
Record which role pairs stay separate and which get merged, by object. People matched across personal and work emails often fall into the same discussion, so cover them in the same rule.
How Dedupely handles people with more than one role
Before combining roles, verify who can see the surviving record and whether purpose-specific preferences remain distinct. One person being both an applicant and a customer does not authorize sharing hiring information with sales.
In Dedupely, you build duplicate searches with filters, so a search can compare customers with customers and leave applicant or partner records out. When a pair is two roles you mean to keep apart, you reject the match, and it stays out of current and future searches. For the pairs that are one person, you set rules for which value wins and preview each merge.
Same person, your decision
A person with several roles is the same person in every record, and that's what makes these pairs hard. Whether they belong on one record depends on who works each role and who should see its data. It also depends on what your reports count and which processes act on it.
Once your team has answered those questions, the cleanup gets simpler. Pairs that are one relationship get merged with the right values. Pairs you mean to keep stay apart from one search to the next.
Frequently asked questions
Is a contact with two roles a duplicate in a CRM?
It depends on your team: if the same team works both roles and reports count people, two records are usually a duplicate worth merging. If the roles need different owners, access, consent or workflows, separate records can be correct. Decide per case and write the rule down before you merge.
Should a customer and a job applicant share one CRM record?
It's case by case: one record can fit when the same people work both roles and everyone with access may see the applicant details. Separate records fit when hiring and sales use different teams, workflows or access rules. Decide with both teams, and write the rule down before you merge.
Can one contact belong to two companies in a CRM?
Yes, in some CRMs: one contact can be associated with more than one company, with one marked as primary. Some CRMs also let you label each relationship. That keeps an advisor at one company and an employee at another on one record, so check how your CRM handles the primary company.
How do I stop intended pairs from showing up as duplicates?
Narrow your searches with a field that separates roles, like record type or source, so each search compares one role with itself. For pairs that still appear, reject the match once you're certain it should stay separate. Write down which role pairs stay apart so everyone running searches follows the same rule.
Which values should win when I merge a person with two roles?
Decide per field, based on the role that matters more to your team. Owner and lifecycle stage often come from the customer record, since that relationship drives revenue. Keep the other role visible with a role field or an extra company link, so the merge doesn't hide it.
Or sign up with Google
HubSpot Marketplace 
