HubSpot Properties
Complete Guide

Think of a Contact record like a paper file. The file has a cover with spaces for a name, phone number, address, and status. Each of those spaces is a property. HubSpot gives you pre-printed spaces (default properties) and lets you add your own blank spaces (custom properties).

Why properties are everything

Property anatomy

Calculated properties

A third category — Calculated properties — are auto-computed by HubSpot and cannot be manually edited. They include:

Field type decision guide

Every property belongs to a Property Group — a labelled section that groups related properties together in the record view. When a rep opens a Contact record, they see properties organised by group in the left sidebar.

How to create a property group

1. Go to Settings → Properties
2. Select the object type (Contact, Company, Deal, etc.)
3. Click "Groups" at the top of the page
4. Click "Create group"
5. Enter a clear, descriptive name (e.g. "BANT Qualification")
6. Save — the group now appears as a section in the record sidebar

1. Choose the object — Contact, Company, Deal, Ticket, or Custom Object. This locks the property to that record type forever.
2. Choose the group — pick an existing custom group or create a new one. If this is a new topic area, create a group first before proceeding.
3. Write the label — clear, plain English, no abbreviations. Example: "Preferred Communication Channel" not "PCC" or "comm_pref."
4. Review the internal name — HubSpot auto-generates this from your label (e.g., preferred_communication_channel). You can edit it now — but not after saving. If you have an integration that will use this property, confirm the naming convention with your dev team first.
5. Add a description — explain what goes here, who fills it in, and example values. This is documentation that saves hours of confusion later.
6. Select the field type — use the decision guide above. For "Preferred Communication Channel" → Radio select (Email / Phone / WhatsApp — one answer, small list, all visible).
7. Add options (if applicable) — for Dropdown/Checkbox/Radio: add all your values. Set a display order. Consider whether you need a default value.
8. Configure settings — Required? (probably no). Hidden from forms? (yes, if internal). Show in sidebar? (yes, if reps need to see it frequently).
9. Save — the property is now live on every record of that object type.

Property history

Every time a property value changes, HubSpot records it in the property history log. You can view this on any record by clicking any property and selecting "View property history." This shows: what the old value was, what the new value is, when it changed, and what source changed it (workflow, manual, import, API). This is invaluable for debugging data quality issues.

Who can create properties

By default, any Super Admin in HubSpot can create custom properties. In larger teams, this quickly becomes a problem. Restrict property creation to 1–2 designated admins who enforce naming conventions and avoid duplication.

Naming conventions — the admin standard

Monthly governance checklist

• 📋
  Audit for duplicate properties — two or more properties storing the same data. Merge via import and archive the redundant one.
• 🗄️
  Archive unused properties — any custom property with 0 records filled in for 6+ months. Archiving hides it from the UI but preserves historical data.
• 📝
  Review description coverage — any custom property without a description should get one added immediately.
• 🏷️
  Enforce naming conventions — rename any properties that don't follow the convention (label change is safe).
• 👁️
  Review sidebar configuration — are the right properties visible on records? Remove low-value properties from default sidebar view.
• 🔒
  Audit required fields — are required fields being filled with real data or placeholder values? Adjust if adoption is poor.

A B2B SaaS company wants their SDRs to qualify leads using the BANT framework (Budget, Authority, Need, Timeline). None of these are default HubSpot Contact properties. Here is how an admin builds them:

Step 1 — Create the property group

Before creating any properties: Settings → Properties → Contacts → Groups → Create group → Name: "BANT Qualification"

Step 2 — Create the properties

Step 3 — Connect to workflow automation

Step 4 — Result

Now the sales manager can report: "What percentage of MQLs reached BANT Score ≥ 3 this month?" SDRs have a structured qualification framework. The pipeline only contains properly qualified leads. SQL-to-close rates improve because the leads entering the pipeline are genuinely ready.

• 1. Using the wrong field type and realising it too late
  "Annual Revenue" stored as Single-line text. "Lead Score" stored as a text field. "Timeline" stored as a number instead of a dropdown. You can't change most field types after creation — you have to delete and rebuild, losing all historical data. Fix: choose field type deliberately, using the decision guide, before saving.
• 2. Creating duplicate properties
  "Source," "Lead Source," "Marketing Source," and "Original Source" all existing simultaneously. Reps don't know which to fill. Reports are split across four fields. Fix: search existing properties before creating. If one already exists, use it.
• 3. Never filling in the description field
  Six months later, nobody knows what "Flag B" means or why it was created. Fix: every custom property gets a description before it goes live. Treat it as required documentation.
• 4. Making too many fields required
  If 14 properties are required to save a Contact, reps enter "n/a," "unknown," or random values just to get past the validation screen. Fix: limit required properties to 3–5 critical fields per object. Let rep adoption drive data quality for non-critical fields.
• 5. Not understanding the "don't overwrite" setting in workflows
  A workflow overwrites a rep's manually-set Lead Status back to "New" every time a new form is submitted. The rep's work is silently erased. Fix: enable "Don't overwrite existing values" on any workflow action that sets a property which may have been filled by a human.
• 6. Using Single checkbox where a Dropdown with Yes/No/Unknown is better
  "Budget Confirmed" as a single checkbox has three states: checked (yes), unchecked (unknown — not no). For true Yes/No/Unknown tracking, a Dropdown with those three options is cleaner and more reportable. Fix: understand the three-state nature of checkboxes before using them for yes/no logic.
• 7. Dumping all custom properties into the default "Contact Information" group
  The record sidebar becomes 40+ properties long, all mixed together. Reps can't find anything. Fix: create named custom groups by function — "Qualification Data," "Marketing Attribution," "CS Fields." Keep the default groups for HubSpot's own properties.
• 8. Never archiving old properties
  Properties from campaigns from 3 years ago, old qualification frameworks, deprecated fields — all still cluttering the property picker and confusing new reps. Fix: quarterly archiving review. Anything with 0 fill rate in 12 months gets archived.

Sample property registry — Contact object

14 field types at a glance

Key rules to remember

• 🔒
  Internal name is permanent — set your label correctly before saving. The internal name cannot be changed.
• ⚠️
  Most field types cannot be changed after creation. Plan your field type before creating.
• 🔄
  Last write wins — the most recent update to a property overwrites the previous value. Use "Don't overwrite" in workflows to protect human-entered data.
• ☑️
  Single checkbox unchecked ≠ false — it means the value is unknown/not set. Build workflow conditions using "is known" not "is equal to true."
• 📋
  Always fill in descriptions — every custom property must have a description explaining its purpose and how to fill it.
• 🗂️
  Custom group first — create a named custom group before adding custom properties. Never dump custom properties into HubSpot's default groups.
• 📊
  Maintain a Property Registry — the #1 governance tool for any CRM admin. Document every custom property with purpose, owner, and status.
• 🔍
  Search before creating — always check if a property already exists before creating a new one. Duplicates are the most common CRM data quality problem.