If you are deciding between a default HubSpot property and a custom one, the best rule is simple: use the default property if it already does the job. Create a custom property only when you need to capture something unique for reporting, automation, integration or process control.
That approach keeps your CRM cleaner, makes reporting more reliable and reduces admin overhead later. In most HubSpot portals, property sprawl does not come from a lack of features. It comes from teams creating new fields before checking what already exists.
In our experience, the most effective HubSpot setups are usually the simplest ones. The goal is not to track everything. It is to track the right data in a way your team can trust and maintain.
|
Property type |
What it is |
Best used for |
Main advantage |
Main risk |
|---|---|---|---|---|
|
Default property |
A standard field created by HubSpot |
Common CRM data like lifecycle stage, lead status, deal amount, create date, owner and source data |
Built to work with HubSpot's tools, reporting and automation out of the box |
Teams sometimes ignore them and duplicate them with custom versions |
|
Custom property |
A field you create yourself |
Business-specific information that HubSpot does not already provide |
Gives you flexibility for your process, data model and reporting needs |
Too many custom fields can clutter the CRM and weaken adoption |
Default HubSpot properties are built into the platform. Custom properties are fields you create to track information that HubSpot does not provide by default.
That difference matters because default properties are often tied more closely to HubSpot's native reporting, automation and object behaviour. In many cases, they are also the fields other teams expect to find when using the CRM.
For example:
If you create custom versions of those fields without a strong reason, you often introduce confusion rather than control.
You should use a default property whenever HubSpot already has a field that captures the data you need in a usable format.
This should always be your starting point. HubSpot's own guidance is to check for an existing default property before creating a custom one. That is sound advice because default properties are usually easier to support across reports, workflows and integrations.
Use a default property when:
A common mistake is creating a custom field because the team does not like the default label. In many cases, the better option is to review the process, training or naming convention before adding more fields.
Create a custom property only when there is a clear business need that default properties cannot cover.
Good reasons include:
A custom property is justified when it helps the business run better, not just when someone asks for another field.
Before creating a custom property, ask these five questions.
Start in the property library and search properly. Check similar names, related objects and existing groups before assuming HubSpot does not have what you need.
If the answer is vague, such as "it might be useful later", do not create it yet. A property should support a clear use case.
If the field is not tied to a meaningful process, it may not deserve a place in the CRM.
This is where many setups go wrong. Data should live on the object where it naturally belongs. For example:
If nobody owns the field, definitions drift, values become inconsistent and reporting becomes unreliable.
If you do need a custom property, set it up with governance in mind from the start.
Create the property on the right record type: contact, company, deal, ticket, product, line item or another supported object. Do not use a contact property to store deal information just because contacts are more familiar to the team.
HubSpot supports multiple field types, and the choice affects validation, usability and reporting. Common options include:
Pick the type based on how the data will actually be used. If the field will drive reporting or workflow logic, controlled options like dropdowns are usually better than free text.
Add a description that explains what the property means, when to use it, which values are allowed and who owns it. This is a small step that saves a lot of confusion later.
For enumerated fields such as dropdowns and checkboxes, keep the options tight and mutually exclusive where possible. Use names your team can understand quickly. If needed, include a naming convention for operational fields, such as prefixes for integration or workflow-only properties.
Before rolling it out widely, check that it appears where users need it, works in reports, behaves correctly in workflows and syncs properly with connected systems.
A few details that are easy to miss, especially if your portal has been live for a while.
HubSpot documents custom property and calculated property limits, but these can vary by subscription and change over time. Rather than relying on an old article or a remembered number, check the live usage view in Data Management > Data Model > Limits. This shows how many custom properties you have created, your usage of calculated properties, and other CRM data model limits that may affect scalability. HubSpot's data usage tracking documentation explains what is tracked and where to find it.
HubSpot's property sync field type allows the same value to be visible across associated records. That can be useful, but it should be used with care. Syncing data is not a substitute for a clean data model. If teams sync too much, it becomes harder to identify where the source of truth actually lives.
Calculated properties can simplify reporting and reduce manual work, but they should solve a real need. Too many calculated fields make the data model harder to maintain, especially when teams no longer remember how values are derived.
There is an important nuance here. When you create a custom product property, HubSpot automatically creates a corresponding synced line item property. But if you create a custom line item property, it does not sync back to products. That matters for quoting, reporting and product data governance. If the field represents a reusable product attribute, define it at the product level first.
Most property issues are not technical. They are governance issues.
Avoid these:
If your portal already has these problems, the answer is usually to clean up before expansion.
If you want your property setup to stay usable as HubSpot grows, put a lightweight governance process in place. This does not need to be bureaucratic. It just needs to be consistent.
Before creating any new property, work through this checklist:
Start with default HubSpot properties and only add custom ones when there is a specific operational reason. That approach gives you a cleaner CRM, stronger reporting and fewer problems as the portal matures.
It also aligns with a broader RevOps principle we come back to often: keep the system as simple as possible, but no simpler than the business requires.
If your HubSpot property setup is getting messy, we can help you review what should stay, what should be merged and what should be removed. A focused HubSpot audit or CRM clean-up can usually improve reporting quality and team adoption faster than adding more fields.
Sources