HubSpot properties: how to name them and when to delete one
A HubSpot property label can be renamed at any time but its internal name cannot, and most field types cannot be changed after creation. Before creating one, decide the type and who populates it. Before deleting one, check which workflows, lists, forms and reports reference it.
By HubReven
Portals do not become unusable through one bad decision. They get there through four hundred properties, most of them empty, created by people who have since left.
Here is how to create them so that does not happen, and how to clean up when it already has.
Two things you cannot change later
The internal name. The label is what people see, and you can rename it freely. The internal name is what the API, workflows and integrations reference, and it is fixed at creation.
So contact_property_1 stays contact_property_1 forever, no matter how many times you rename the
label. Every integration mapping and every exported report will carry that name.
Write the internal name deliberately: lowercase, underscores, descriptive, and consistent with whatever convention you have. If you have no convention, adopt one in the next ten minutes.
The field type, mostly. Converting between most types is not supported after creation. Getting this wrong means creating a second property, migrating values across, updating everything that references the first one, and deleting it.
Picking the type
The decisions people get wrong, in order of frequency.
Dropdown, not single line text, whenever the values come from a known list. Free text produces "USA", "U.S.A.", "United States" and "us" in the same column, and no report can group them.
Number, not text, for anything you will sum, average or filter by range. A number stored as text sorts alphabetically, so 100 comes before 20.
Date picker, not text. Same reason. Text dates cannot drive a workflow delay or a date filter.
Checkbox for a real yes or no. Not a dropdown with Yes and No, which allows a third state of empty that nobody defined.
Multiple checkboxes when several values are true at once. "Products owned" is multiple checkboxes. Making it a dropdown forces a choice that misrepresents reality.
Three questions before creating one
Who populates this, and when? If the answer is "the rep, during the call", check that they can actually know it at that point. A property nobody can fill in at the moment it is asked for stays empty forever and then poisons a report.
What decision does it drive? If nothing changes based on the value, it is a note, not a property. Notes belong in the notes field.
Does something similar already exist? Search the existing properties first. Most portals have three variations of the same idea because nobody looked.
The cleanup pass
For a portal that already has hundreds, work in this order.
1. Export the property list with fill rates. Properties used on fewer than 5% of records are your candidates. This is usually a third of the list.
2. Check references before touching anything. For each candidate, find what uses it: workflows, active lists, forms, reports and dashboards, and integration mappings. HubSpot shows some of these on the property itself, but integration mappings live outside the portal and will not appear. Deleting a property an integration writes to breaks the integration silently.
3. Archive rather than delete. Archiving removes it from the interface and keeps the data. If nobody notices in a quarter, delete it then. Deletion is permanent and there is no reason to rush it.
4. Merge duplicates. Where three properties mean the same thing, pick one, migrate values into it, update references, archive the others.
5. Fix the types that are wrong. Text fields that should be dropdowns, with values that already vary. Create the new property, map the existing values, migrate, update references, archive the old.
6. Write down the convention. So the next person creating a property has something to follow.
Required fields, used sparingly
The instinct when data is missing is to make the field required. It is almost always the wrong move.
Required fields that the person cannot know at that moment get filled with whatever passes validation. You do not get data, you get noise that looks like data, which is worse because now the report appears trustworthy.
Make a field required only when the person genuinely has the answer at the moment they are asked, and when a record without it is genuinely invalid. Everything else is a design problem rather than a discipline problem.
Where this shows up
Property sprawl is the first of the six areas in a portal audit, because it explains most of the others. Reports read zero because their properties are empty. Workflows never enrol because they test a property nobody fills. Imports fail because a required field is not in the source file.
Fixing the properties fixes several symptoms at once, and it is work your own admin can do.
Frequently asked questions
Can I rename a HubSpot property?
You can rename the label at any time. The internal name is fixed at creation and is what the API, workflows and integrations reference, so choose it carefully.
Can I change a property's field type?
Most type changes are not supported after creation. The workaround is creating a new property with the correct type, migrating the values, updating every reference, then archiving the old one.
Is it safe to delete a HubSpot property?
Check what references it first: workflows, lists, forms, reports and any integration mapping, which lives outside the portal. Archive instead of deleting, and delete only after a quarter with no complaints.
How many properties is too many?
The count matters less than the fill rate. Properties populated on under 5% of records are actively harmful, because every report built on them displays confidently wrong numbers.
Get the next one