How to Create Custom Deal Properties in HubSpot (Step-by-Step)

What a custom deal property is, and when you need one

A deal property is a field stored against the deal object. HubSpot ships with standard properties, and you can add your own custom ones to capture anything the standard set misses: contract length, renewal date, lead source detail, product line, deal type, or a qualification field your sales team scores on.

You need a custom deal property when there is information you want to filter, segment, automate, or report on at the deal level, and there is no existing field that holds it cleanly. If you are forcing data into the deal name or a notes field to work around a missing property, that is the signal to create one.

How to create a custom deal property in HubSpot

You will need admin access, or at least permission to edit properties. The flow takes a couple of minutes.

Open property settings. Click the settings icon in the main navigation, then go to Properties in the left-hand menu.

Select the Deal object. In the "Select an object" dropdown, choose Deal properties so your new field is created against deals rather than contacts or companies.

Create the property. Click Create property. Set a clear label, and review the auto-generated internal name. The internal name is what integrations and the API use, so keep it consistent and readable.

Choose a group and add a description. Assign the property to a logical group, and write a short description explaining what the field is for and how it should be filled in. This is the single most ignored step and the one that prevents the most confusion later.

Pick the field type. Choose the type that matches the data: single-line text, number, date picker, dropdown select, multiple checkboxes, and so on. For anything with a fixed set of answers, use a dropdown or checkbox rather than free text. Structured options are reportable and filterable; free text is neither.

Define the options and rules. For dropdowns and checkboxes, add your option values. Decide whether the field should be required at a given pipeline stage to enforce data quality at the point of entry.

Save. The property now exists and is available across deal records, views, lists, workflows, and reporting.

How to make the property visible on deal records

Creating a property does not automatically show it to your team. To surface it during deal creation and on the record itself:

Go to Settings, then Objects, then Deals.

Find the section for the properties your team sees when creating and editing deals.

Search for your new property and add it to the create form and the record sidebar.

Save. The field now appears where reps actually work, which is what gets it filled in.

If a property is created but never surfaced, it stays empty, and an empty property is worse than no property because it implies data exists when it does not.

The architecture decisions that keep your pipeline clean

Creating one property is easy. Creating a property model that scales across a mid-market sales team is where most CRMs come undone. A few principles keep deal data trustworthy:

Field type is a reporting decision, not a formatting one. Every free-text field is a field you cannot report on cleanly. Use dropdowns and numbers wherever the data has a finite shape. You can always loosen a field later, but you cannot easily clean years of inconsistent free text.

Required-at-stage beats required-always. Forcing every field on deal creation slows reps down and produces junk data entered just to get past the form. Require fields at the pipeline stage where the answer is actually known.

One source of truth per data point. If close probability lives in three properties, none of them is right. Map each data point to a single property before you create the next one.

Naming conventions matter at scale. Consistent labels and internal names make properties findable, and they keep your integrations and reporting predictable as the property count grows.

Plan for the data coming in from other systems. If deal data is synced from finance, support, or a product database, the property design has to match the shape of that source. This is where a property model and your data engineering setup have to agree, or you get sync errors and duplicate fields.

Why custom deal properties power clean reporting

Good deal properties are the foundation of good pipeline reporting. Forecast accuracy, win-rate analysis, deal-velocity tracking, and revenue attribution all read from deal-level fields. If those fields are inconsistent, optional, or duplicated, every report built on them inherits the problem. A well-structured property model means your dashboards reflect reality, and your team can trust the numbers enough to act on them.

This is also where integrations earn their place. When deal data flows in from other tools, the property structure determines whether that data lands cleanly or creates noise. If you are connecting HubSpot to other systems, our guide to connecting anything with HubSpot integrations covers how to map external data to the right fields, and the integrations hub shows what is possible.

When to bring in a CRM implementation partner

If you are adding a handful of properties, the steps above are all you need. If you are designing a property model for a mid-market sales team, migrating from another CRM, or your existing HubSpot is already cluttered with overlapping fields nobody trusts, the design work matters more than the clicks.

That is the work we do. Our HubSpot CRM implementation service builds the architecture for B2B teams who have outgrown spreadsheets but will not be boxed in by off-the-shelf defaults: clean property models, enforced data quality, pipelines that match how you actually sell, and reporting you can run the business on.