HubSpot Custom Properties vs Default: When to Add One

A HubSpot property is just a field on a record, like Email or Deal Amount. Default properties ship with the CRM out of the box. Custom properties are ones you build yourself. The rule of thumb: use a default property if it already captures what you need, and only create a custom one when there’s a genuine gap in what HubSpot gives you.

If you’ve ever stared at the “Create property” button in HubSpot and wondered whether you actually need it, you’re not alone. New admins tend to swing one of two ways: they either never touch properties at all, or they go overboard and build a custom field for every little thing the sales team asks for. Neither approach ends well.

This post breaks down the actual difference between default and custom properties, gives you a simple framework for deciding when a new one is warranted, and shows you the mess that happens when teams skip that step.

What’s the difference between a default property and a custom property?

A property in HubSpot is a data field attached to a record, whether that’s a contact, company, deal, or ticket. Think of a contact record like a form: Name, Email, and Phone are all separate fields, and each field is a property.

Default properties (sometimes called standard properties) are pre-built by HubSpot and come with every account. They cover the basics: contact name, email address, phone number, company name, deal stage, and so on. The contacts object alone ships with more than 160 of these built-in fields, and companies, deals, and tickets each have their own sets on top of that.

Custom properties are fields you create yourself to store information HubSpot doesn’t already track. Say you sell industrial equipment and need to log which certification a customer’s facility holds. There’s no default field for that, so you’d build a custom property to capture it.

Here’s the part people miss: you can’t delete or edit a default property’s core behavior. You can edit some things, like the dropdown options on a picklist, but the underlying field itself stays put. If you want a cleaner version of an existing field (say, a dropdown instead of free text), you’re usually building a custom property alongside it, not replacing the default one.

It’s worth being specific about what “can’t edit the core behavior” actually means in practice, since it trips people up. You can rename a default property’s label, move it to a different property group, and adjust certain field-level settings. What you can’t do is change its underlying field type (turning a free-text field into a number field, for instance) or delete it outright, even if your team never uses it. That permanence is exactly why checking before you build matters so much, a custom property you regret creating is far easier to walk back than a default one you’re stuck with forever.

Why does the distinction actually matter?

It matters because default and custom properties don’t play the same role in your CRM. Default fields are what most of HubSpot’s native reporting, workflows, and integrations expect to see. When you build a parallel custom field instead of using the one that’s already there, you split your data across two places and nobody’s quite sure which one is “correct.”

That’s how property sprawl happens. It’s rarely a case of teams needing more features. Most of the time, it’s someone creating a new field before checking what already exists in the portal.

Honestly, most of the CRM messes I’ve seen in these situations aren’t a properties problem at all, they’re a “nobody checked first” problem. A rep needed to track something, didn’t know a field for it already existed, and created a duplicate. Multiply that across a sales team for a year and you’ve got a properties list nobody trusts.

The fix isn’t more governance software. It’s a five-minute habit: search the existing property list before you build anything new.

Property sprawl also tends to compound in a specific, predictable way, which is worth understanding so you can spot it early. The first duplicate field rarely causes any visible problem, one rep uses it, nobody else notices. The damage shows up months later, once a report or workflow was built referencing the “wrong” one of the two fields, and now half your contacts have data in the field the report ignores. Untangling that after the fact means auditing every record, deciding which field actually holds the correct data, and migrating values, a cleanup job that’s entirely avoidable if someone had just searched the property list first.

When should you actually create a custom property?

Here’s a simple framework. Ask these questions in order before you hit “Create property.”

1. Does a default property already capture this? Search the property list for the object (contact, company, deal, or ticket) first. If it’s there, use it instead of duplicating it.
2. Is the default field the wrong format, not missing entirely? If the data exists but as free text when you need a dropdown, that’s an editing job, not necessarily a new-property job. You can often adjust the field type or the picklist options on many default properties without building a duplicate.
3. Is this data unique to how your business operates? Things like a renewal date tied to your specific contract terms, a product tier that only your company sells, or an internal lead score your team built are all fair game for a custom property.
4. Will this field feed a report, workflow, or segmentation you actually plan to use? If you can’t name the report or automation that will use this data, you probably don’t need the field yet.
5. Have you checked with other teams who touch this object? A field that makes sense to sales might duplicate something marketing already tracks under a different name.

If you get through all five and there’s still a genuine gap, go ahead and build the custom property.

Pro tip: before creating a picklist-style custom property, check whether the default version of that field already exists with different options. Editing the existing dropdown to match your business (say, trimming HubSpot’s long default industry list down to the five or six industries you actually sell into) is usually faster and cleaner than building a parallel custom field.

Question four deserves a bit more weight than the others, since it’s the one most often skipped in practice. It’s tempting to create a field because it feels like useful information to have on hand, even without a specific report or workflow in mind yet. The problem is that “might be useful someday” fields are exactly the ones that sit empty, half-filled, or forgotten a year later, cluttering the property list for everyone else without ever earning their keep. If you genuinely can’t name what will use the data, it’s usually fine to wait until the actual need shows up.

What are the technical limits on custom properties?

HubSpot caps how many custom properties you can create, and the limit depends on your subscription tier. If you’re not sure which tier your company is on or should be on, it’s worth reading through a comparison of HubSpot’s Free, Starter, and Professional tiers before you commit to a properties strategy, since the tier you’re on affects what you can build.

Free accounts are capped at a small number of custom properties, while paid Professional and Enterprise plans allow far more per object. That ceiling exists for a reason: HubSpot wants you to actually use the fields you create, not hoard them.

Dropdown-style (enumeration) properties also have their own internal limit on how many options a single field can hold. If you’re building a picklist with thousands of options, you’ll eventually hit that ceiling too.

These limits matter more for growing teams than they might initially seem to. A company that starts with a handful of custom fields on a Free or Starter plan can hit its ceiling surprisingly fast once multiple teams start adding properties independently, which is yet another reason the “search before you build” habit pays off, since every unnecessary duplicate field is also quietly eating into a limited, finite budget of properties you’re allowed to create.

A quick checklist before you create a new property

• Searched the existing property list for this object and confirmed nothing similar exists
• Named the specific report, workflow, or segment this new field will support
• Picked the right field type (single-line text, dropdown, number, date, etc.) instead of defaulting to free text
• Written a short description so other users know what the field is for
• Confirmed with any other team that touches this object that they don’t already track this somewhere else
• Assigned the property to a logical group instead of leaving it uncategorized

Properties feed directly into automation, so once you’ve got your fields sorted, it’s worth understanding how a HubSpot workflow actually uses that data to trigger emails, tasks, or updates. A clean property setup is what makes those workflows reliable instead of flaky.

Worth adding to that same checklist habit: revisit your property list periodically, not just at the moment of creating something new. A quarterly pass through each object’s property group, checking for fields that have sat empty for months or clearly duplicate another field under a slightly different name, catches the sprawl that accumulates even when everyone individually followed the checklist above in the moment.

Summary

Default HubSpot properties ship with every account, over 160 on the contacts object alone, and can’t be deleted or have their core field type changed, though you can edit things like dropdown options. Custom properties exist to fill genuine gaps, data unique to your business that no default field captures, but creating one before checking whether a default property already covers it is the single biggest cause of property sprawl and the “messy CRM” complaints that follow.

The five-question framework, checking for an existing default field, confirming it’s a format problem rather than a missing field, verifying the data is genuinely unique to your business, naming the specific report or workflow that will use it, and checking with other teams first, catches most unnecessary custom properties before they’re built. HubSpot’s per-tier limits on custom properties make this habit matter even more for growing teams, since every unnecessary duplicate field eats into a finite budget shared across the whole organization.

Frequently asked

Can I delete a default HubSpot property I don’t like?+

No. Default properties can’t be deleted or fundamentally changed, though you can often edit dropdown options or move them into a different property group to reduce clutter.

How many custom properties can I create in HubSpot?+

It depends on your plan. Free accounts have a much smaller cap than paid Professional and Enterprise accounts, which allow up to 1,000 custom properties per object.

What happens if two teams create separate custom properties for the same data?+

You end up with duplicate, half-filled fields and reports that don’t match. This is the single biggest cause of “messy CRM” complaints, and it’s almost always solved by checking existing properties before building new ones, not by adding more fields.

Should I use a custom property or a custom object?+

A custom property adds a new field to an existing record type like contacts or deals. A custom object creates an entirely new type of record with its own properties and pipeline logic, and it requires an Enterprise-tier subscription. Most beginner use cases only need a custom property.

Is it ever okay to create a custom property that duplicates a default one?+

Sometimes, but only when the default field’s format genuinely doesn’t work for you and can’t be edited to fit. Even then, name the custom version clearly so your team knows which field is the one to trust.