Creating a property in HubSpot takes thirty seconds. Deciding whether you should create it — and naming it so the next person understands it — is the part that keeps your portal usable. Properties are the fields that store everything HubSpot knows about a record, and the way you create, name, and govern them decides whether your reporting stays trustworthy or turns into a junk drawer of half-used fields. Most reporting problems we see trace back to property sprawl, not missing data. Here's the practitioner's read on doing it right.
A property is a single field on a record — like a contact's job title, a deal's amount, or a company's industry — and every property has a type that controls what data it can hold. Each object (contacts, companies, deals, tickets, and custom objects) has its own set of properties. HubSpot ships with many default ones, and you can add custom properties for anything specific to your business. The field type matters enormously: a dropdown forces clean, consistent choices; a free-text field invites ten spellings of the same answer. Picking the right type at creation time is the difference between a property you can report on and one you can't.
Go to property settings, choose the object, pick a clear field type, and define the options before anyone starts using it. In HubSpot, open Settings, then Properties, choose the object the property belongs to, and create the property. The steps that actually matter:
Worked example: instead of a free-text Lead Source field that fills up with "LinkedIn," "linkedin," "LI," and "Linkedin Ad," create a dropdown with a fixed set of sources. Now your source report actually adds up, because the data can only ever be one of the agreed values.
Editing a property's options or type can affect historical data, reports, workflows, and integrations that depend on it — so check what's connected before you change it. Renaming a property's label is safe. But changing field types, deleting dropdown options, or merging values can break things downstream. Before you edit, ask: is this property used in any active workflows, lists, reports, or integrations? Deleting an option that records already use can strip the value from those records. If you need to retire a value, the safer path is often to bulk update the affected records to a new value first, then remove the old option once nothing references it.
Treat property creation as a governed decision, with a naming convention and an owner — not a free-for-all every rep can do on a whim. The fastest way to ruin reporting is to let everyone create their own fields. Three rules keep it clean:
Properties are the schema of your business inside HubSpot, and most teams treat them like sticky notes. The portals that stay healthy after two years aren't the ones with the most fields — they're the ones with the fewest, each named clearly, typed correctly, and owned by someone. When a CRM gets hard to report on, the cause is almost never a missing feature. It's forty overlapping properties nobody agreed on. Govern the data model early and you avoid a painful cleanup later.
Drowning in duplicate or unused properties? Book a 30-minute portal audit — we'll tell you straight which fields to keep, merge, or retire, and how to set a naming standard that holds. For the bigger picture, see how we approach HubSpot implementation and optimization.
What's the difference between a default and a custom property?
Default properties ship with HubSpot and cover common fields like email, deal amount, and lifecycle stage. Custom properties are ones you create for data specific to your business. Both behave the same in reports and workflows.
Can I change a property's field type after creating it?
Some type changes are allowed and some aren't, and even allowed changes can affect existing data and anything that depends on the field. Check workflows, lists, reports, and integrations first, and test on a small set before changing a type on a heavily used property.
What happens if I delete a property?
Deleting a property removes the field and its stored values from records. HubSpot keeps deleted properties recoverable for a limited window, but anything referencing it — reports, workflows, integrations — can break. Export the data and check dependencies before deleting.
How do I avoid duplicate or messy properties?
Use a naming convention, give one person final say on new fields, and require a clear use for every property before it's created. A short, well-governed property list reports far better than a long, ad-hoc one.