If you have ever built a HubSpot segment, set up a workflow, or connected an integration, you have worked with contact properties whether you knew the term or not. Properties are the fields that hold everything HubSpot knows about a contact, and how well you set them up decides whether your CRM stays clean and useful or turns into a sprawl of half-filled fields nobody trusts.
This guide covers what contact properties are, the default ones HubSpot gives you, how to create and manage custom properties, the field types that matter, and the naming rules that quietly break integrations. If you are newer to HubSpot data in general, the HubSpot Notes guide is a good companion to this one.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
What is a HubSpot contact property
A contact property is a single field on the Contact object that stores one piece of information about a contact. First Name is a property. Email is a property. So is Lifecycle Stage, Lead Status, and any custom field your team adds. Together, the properties on a record make up everything HubSpot knows about that person.
Every property is made up of three parts, and understanding the difference between them saves a lot of confusion later:
Label
The human-readable name you see in the HubSpot interface, like "Lifecycle Stage" or "Annual Contract Value." You can rename a label at any time without breaking anything.
Internal name
The behind-the-scenes identifier that the API, integrations, imports, and workflows actually reference, like
lifecyclestageorannual_contract_value. This is generated from the label when you first create the property and is effectively permanent.Field type
What kind of value the property can hold, such as single-line text, a dropdown of fixed options, a date, a number, or a checkbox. This controls how you can filter and report on the data.
Default contact properties in HubSpot
Every HubSpot account starts with a set of default contact properties, sometimes called system or HubSpot-defined properties. You cannot delete these, though you can hide ones you do not use. They cover the fields almost every business needs, plus a handful HubSpot populates automatically.
Some of the default properties you will use most often:
First Name, Last Name, and Email
The core identity fields. Email doubles as the de-duplication key HubSpot uses to decide whether an incoming contact is new or an existing record.
Lifecycle Stage
A dropdown that tracks where a contact sits in your funnel, from Subscriber and Lead through Marketing Qualified Lead, Sales Qualified Lead, Opportunity, and Customer.
Lead Status
A separate dropdown your sales team controls to track outreach state, like New, Open, In Progress, or Unqualified.
Create Date and Last Activity Date
Timestamps HubSpot sets and maintains for you. These are read-only and power a lot of reporting and time-based automation.
Contact Owner
The user assigned to the contact, used throughout routing, permissions, and reporting.
There are dozens more, including analytics fields HubSpot fills in from tracking, like original source and number of page views. The point is not to memorize them. It is to check what already exists before you create something new, because the most common custom-property mistake is rebuilding a field HubSpot already gives you.
Before you create a custom property, search the existing ones. Half the "missing" fields teams want already ship with HubSpot under a slightly different name.
Custom contact properties
Custom properties are the fields you create to capture data specific to your business that HubSpot does not provide out of the box. Think Contract Value, Onboarding Status, Account Region, Preferred Contact Method, or a renewal date. They behave exactly like default properties in segments, workflows, and reports, with one difference: you own them, so you can edit and delete them.
How to create a custom contact property
- 1
Open property settings
Go to Settings, then Properties in the Data Management section. Set the object dropdown to Contact.
- 2
Create the property
Click Create property. Choose a property group to file it under, then give it a clear label. The internal name is generated from the label automatically, so name it well the first time.
- 3
Pick the field type
Choose the field type that matches the data. This is the decision that matters most, because it determines how you can filter and report on the value later.
- 4
Configure options and rules
For dropdowns and checkboxes, define the available options. Set whether the field is required in forms and which teams can edit it.
- 5
Save and test
Save the property, then open a contact record to confirm it appears where you expect and accepts the values you intended.
Choosing the right field type
The field type is the part people rush and regret. A value stored as free text cannot be filtered or charted cleanly, while the same value stored as a dropdown can. Pick the most structured type the data allows.
Single-line text
Short freeform values like a job title or a referral source. Flexible, but hard to report on because every entry can be slightly different.
Multi-line text
Longer freeform notes. Useful for context, but not something you segment or chart on.
Dropdown select
A fixed list where the contact has exactly one value, like Account Region or Plan Tier. The workhorse for clean, reportable data.
Multiple checkboxes
A fixed list where more than one value can apply, like Products Interested In.
Number
Numeric values you want to sum, average, or use in math, like Contract Value or Employee Count.
Date picker
Calendar dates like Renewal Date or Contract Start, which you can use in time-based workflows and reports.
Single checkbox
A simple yes or no flag, like "NDA Signed."
How many custom properties should you create
HubSpot lets you create a large number of custom properties per object, up to 1,000 on most paid tiers, with lower limits on the free CRM. You will almost never hit that ceiling, and that is exactly the trap.
The real limit is not technical, it is human. Every property you add is a field someone has to fill in, keep current, and trust. A record with 40 mostly-empty custom fields is harder to use than one with 12 that are always accurate. The teams with the cleanest HubSpot instances are usually the ones that say no to most property requests.
When a custom property earns its place
- You will segment, filter, or report on the value
- A workflow or integration needs to read or write it
- The value is structured and someone owns keeping it current
When you should not create one
- It just mirrors data that lives in another tool
- Only one person would ever look at it
- It is freeform context better suited to a note than a field
That last point on the right is where most CRMs go wrong. A property is the right home for structured, reportable data. It is the wrong home for the rich, messy context of a sales conversation. For more on that distinction, see why HubSpot contact notes increase sales.
Properties and integrations: the internal name trap
This is the part that costs teams the most time and gets the least attention. Any tool that reads from or writes to HubSpot, whether it is an import, the API, Zapier, or a native integration, binds to the property's internal name, not its label.
That has two practical consequences:
Renaming a label is safe
You can clean up "ACV (new)" to "Annual Contract Value" without breaking a single integration, because the internal name stays the same underneath.
The internal name is effectively permanent
HubSpot generates the internal name from your label the moment you create the property, and you cannot edit it afterward through the interface. A sloppy first label like "temp field 2" leaves you with a permanent internal name to match. Name deliberately the first time.
When you map fields during an import or set up an integration, always confirm you are mapping to the internal name you intend, especially if you have several similarly-labeled properties. If you are connecting Notion and HubSpot, our Notion HubSpot integration guide walks through how field mapping works across four different methods.
The question to ask before creating a property
A lot of custom properties exist for one reason: a team uses another tool, usually a spreadsheet or Notion, and wants that data visible inside HubSpot too. So they build a custom property for each field and then maintain a sync, by hand or with automation, to keep the two in step.
That works, but it doubles your maintenance. Every field now lives in two places, drifts out of sync, and needs a process to reconcile. Before you go down that road, it is worth asking whether the data needs to be a HubSpot property at all, or whether it just needs to be visible on the record.
Not every field that should appear in HubSpot needs to become a HubSpot property. Sometimes it just needs to be visible there, while it continues to live where your team actually maintains it.
This is the gap NoteLinker fills. Instead of mirroring your Notion databases into a parallel set of custom properties, NoteLinker shows your Notion rows directly on the HubSpot contact and deal records. It matches each row to the contact by email, so the data stays in Notion, where your team keeps it current, and shows up live in HubSpot, where your reps need to see it. No duplicate fields, no two-way sync to babysit. For the contact side specifically, see how to sync Notion contacts to HubSpot.
See your Notion data on HubSpot records without the property sprawl
NoteLinker surfaces your Notion database rows right on the HubSpot contact and deal timeline, matched by email. Keep the data in Notion, see it in HubSpot.
Managing properties over time
Properties are not set-and-forget. A healthy HubSpot instance gets a periodic review, the same way a database gets pruned.
A quarterly property review
Find properties with low fill rates and decide whether to fix the process or delete the field.
Look for duplicate or near-duplicate properties created by different people and consolidate them.
Confirm dropdown options are still current and have not sprawled into near-identical variants.
Check that required fields are actually required and not just slowing down form fills.
Archive or hide default properties your team never uses to reduce noise on the record.
Empty and inconsistent properties are usually a symptom of a deeper problem: reps not updating the CRM. If that sounds familiar, the fix is rarely more fields. It is a smaller, better-maintained set and a workflow that fits how reps actually work, which we cover in how to get sales reps to actually update HubSpot.
