How to approach contact structure

Developer Support APIs & Integrations
1

I have a bit of an issue in how to structure orders and contacts. Our platform does a lot of its transactions over the phone and users can create online accounts later on which link to phone numbers that they may or may not have already used to transact.

- A customer may have several telephone numbers attached to their account.

- An account may have transacted and a telephone number may have transacted before they are linked.

- Telephone numbers do not necessarily stay attached to the account and may move to a new email address.

How can I set this up to keep track of transactions by telephone number and join / break joins between telephone numbers and email addresses?

2

Hey @NEynon that’s honestly a great, and very tricky question.

It’s ultimately an object priority and association question within HubSpot in my opinion.

Within HubSpot for all intents and purposes an email == a unique contact. It sounds like you have situations where a contact exists but an interaction with them does not always equal a unique value for that contact.

The way I always see it is that a contact record should be seen as relatively permanent, yes a contact may update their phone number but the contact updates and grows with that. If you’re expecting a phone number to be an identifier for a specific interaction with a contact then that phone number might not make sense to live within a contact record.

Could you provide more information on what kind of interactions customers/leads may be using different numbers on? Would it make more sense to have these interactions tracked under tickets, or even notes?

For example I could have Tom, Tom@tom.com, 55-555-555. However if Tom@tom.com opens a ticket they could provide the email tom@freemail.com and 01-444-4444 as a number on the ticket. That ticket could be associated to the main contact record and replied to as an individual record, but the main contact record will stay the same unless told to update.

3

Hi Tom, thanks for the response. The scenario is this:

Tom has a telephone number 55-555-555 which he uses to make a purchase, he later sets up an account tom@tom.com which he links to his other number 01-444-4444 which he uses to make further purchases. At some later point he adds his original number 55-555-555 to the account.

I can see this working if we could make individual contacts for each of the telephone numbers and for the email address and somehow make and break associations between the contacts or if the telephone number becomes the primary key rather than the email address but it’s not clear that hubspot can handle this.

4

Hey @NEynon , this is a genuinely hard modeling problem, and you’ve already identified the core constraint correctly. HubSpot is still fundamentally email-centric. A contact record represents a person, and email remains the primary, immutable identifier.

Phone numbers are treated as mutable attributes, not identities. That means HubSpot can’t really support “phone number as a first-class entity” in the same way your business logic does.

With how HubSpot works today, the cleanest mental model is this: contacts are people, transactions are events.

If phone numbers can move, be shared, or exist before an account is created, they shouldn’t be the backbone of the contact record itself. Instead, they should live on a transactional object that can change over time.

In practice, that usually means one of two patterns. The most common is to keep a single contact per real person (anchored to the email once it exists), and store each purchase or call as a deal, ticket, or custom object. Each transaction record captures the phone number used at that moment.

When Tom later links accounts or adds a new number, you associate those past transaction records to the same contact, but you don’t try to retroactively “merge identities” at the phone level.

This avoids fighting HubSpot’s identity rules. HubSpot’s contact model and deduping behavior are outlined here (Deduplicate records in HubSpot )

The alternative, creating one contact per phone number and trying to associate and disassociate contacts over time, tends to break down quickly. Associations between contacts exist, but HubSpot doesn’t treat them as identity joins. Reporting, attribution, and automation all assume one primary contact, so you end up constantly undoing merges or duplicating history.

So in your example, Tom ultimately becomes one contact once the email exists. The different phone numbers remain historical facts on the transaction records. The contact evolves, but the events keep their original context. That model scales better and stays aligned with HubSpot’s core assumptions.

If you want, the next question to clarify is which object today represents a “purchase” for you, because that usually determines whether deals, tickets, or a custom object is the right home for those phone numbers.