HubSpot custom properties are the difference between a CRM that runs your business and a CRM that just stores names and email addresses. HubSpot ships with 200+ default properties, but the fields that actually drive your sales process, your reporting, and your automation are the custom ones you build yourself.
This guide walks through exactly how to set up HubSpot custom properties the right way: what to create, what to avoid, and the naming conventions that prevent a five-person team from turning a clean CRM into an unusable mess by year two.
A custom property is a field you add to a HubSpot object (contact, company, deal, ticket, or custom object) that captures information HubSpot doesn't track by default. Industry. MRR. Contract renewal date. Implementation phase. Anything specific to how your business runs.
Every property has three things that matter: its field type (single-line text, dropdown, number, date, checkbox, multi-select), its object (contact, company, deal, etc.), and its property group (the bucket it shows up in when you view a record).
The single biggest mistake I see with HubSpot custom properties: teams create them ad-hoc as they go. Six months later you have 40 fields with inconsistent names, nobody remembers what "Status 2" means, and reporting is broken.
Before you create a single property, write a data dictionary. For each field, document:
A Google Sheet or Notion doc works fine. This dictionary becomes the source of truth for every property decision.
Open-text fields are where reporting goes to die. If you want to track lead source and you use a text field, you'll end up with "LinkedIn," "linkedin," "LI," "Linked In," and "linkedin.com". All different values, all uncountable in a report.
Default to dropdown select, multi-select, or checkbox field types for anything categorical: industry, lifecycle stage modifier, region, persona, product interest, lead source. Reserve open text for things that truly are unique per contact, like job title or a specific request note.
Pick a naming convention on day one and enforce it. My default for client builds:
Consistency matters more than the specific convention. Pick one, write it in the data dictionary, and make every new property follow it.
In every HubSpot portal I manage, exactly one person has the power to create custom properties. Everyone else submits a request. This single rule prevents 90% of data-quality problems that show up after year one.
Set up a simple request process in your HubSpot instance: a shared form that captures the new property's name, object, type, options, owner, and business justification. The admin reviews, decides if it duplicates an existing field, and creates it following the naming convention.
Starting point list: these 12 custom properties are in almost every B2B HubSpot portal I set up:
Custom properties grow. Every 90 days, pull the full property list (Settings → Properties) and review:
Set a quarterly recurring task in HubSpot with the data dictionary owner assigned. This is the single most under-rated HubSpot admin habit in the industry.
The limit depends on your HubSpot subscription. Free tools have a low cap, Starter and Professional allow far more, and Enterprise tiers permit hundreds to thousands of custom properties per object. Check Settings → Properties → "Data quality" to see your current count versus your tier's limit. If you downgrade tiers, existing properties remain visible and editable but you can't create new ones beyond the lower limit.
Contact properties describe a person: their role, engagement, personal data. Company properties describe an organization: size, industry, revenue, tech stack. Information that applies to the whole company (annual revenue, employee count, industry) belongs on the company object, not duplicated on every contact. HubSpot automatically associates contacts to companies and you can reference company properties from contact-level workflows and reports.
Default to dropdown or checkbox whenever the value is categorical. Open text is only appropriate for truly unique values: job titles, specific notes, free-form descriptions. Dropdowns give you clean reporting, segmentable lists, and consistent automation triggers. Text fields make all three of those harder because every typo or formatting variation creates a separate "value" in reports.
Yes. In any contact, company, deal, or ticket list view, select multiple records and click "Edit" at the top. You can update one or more custom properties across the selection in a single action. For large-scale updates across thousands of records, use an import with the "Update existing records" option. This respects property types and won't overwrite with blank values.
Yes. Custom properties live on the core CRM layer, which is shared across Marketing Hub, Sales Hub, Service Hub, and CMS Hub. A custom contact property you create in Sales Hub is immediately usable in Marketing Hub workflows, Service Hub ticket automation, and CMS Hub personalization tokens. This shared database is the core architectural advantage of HubSpot over modular CRM ecosystems.
Custom properties look like a small setup task. In reality they're the schema your entire revenue engine runs on: every workflow, every report, every piece of sales automation references them. Get the foundation wrong and you'll rebuild everything 18 months from now.
If you're setting up HubSpot for the first time or migrating from another CRM, the configuration decisions you make in week one affect everything that follows. Book a call with Your HubSpot Expert. I'll build your property architecture before you touch a single setting, so you start with a CRM that's ready to scale.