When two fields appear to mean the same thing, users should not have to infer which one the business trusts. A property catalog needs decisions about purpose, ownership and change, not only better labels.
We recommend managing HubSpot properties as part of the business process they support. Every new field should have a reason to exist, an owner who can explain it and a plan for what happens when it stops being useful.
TLDR: Define a property's business meaning, object, source, allowed values, owner and dependencies before adding it. Use a naming convention that people can apply consistently. Review changes and retirement against the processes that use the field, with evidence and approval before any destructive action.
Ask the requester to complete a plain sentence: “We need this information so that this person or process can make this decision.” If the team cannot finish that sentence, pause the request and clarify the requirement.
HubSpot provides default properties and allows custom properties to store information on records. HubSpot's property documentation is the reference for reviewing the available fields and their configuration.
Before adding a custom field, inspect the existing catalog and definitions. A similar label is not enough to prove that a field is suitable, but it is a reason to investigate before creating another one.
The HubSpot portal audit checklist can help identify property issues. Governance determines who resolves them and how the decisions remain consistent afterward.
We recommend a register that describes meaning and responsibility alongside the technical identifiers. It can be a maintained document or another approved system; the value comes from keeping it accurate and available to the people changing the CRM.
Keep a history of approved definition changes. Otherwise, a report can appear to compare the same field over time while its meaning has changed underneath it.
Use labels that describe the business concept without requiring the reader to know the project that created it. Avoid temporary campaign names or unexplained abbreviations unless the field is intentionally limited to that purpose.
Document how your team proposes internal identifiers for new fields and how it records identifiers already in use. Do not treat renaming or recreating a field as a cosmetic action without checking the current product behavior and dependencies.
Hypothetical example: A field called “Tier” could mean customer service level, account priority or product package. The problem is not solved by choosing a cleaner spelling. The team needs separate definitions or a documented decision that only one of those concepts belongs in that field.
For every approved option, include a plain-language meaning and the rule for selecting it. Define whether an empty value means unknown, not applicable or not yet reviewed. Those meanings should not be interchangeable by accident.
As you review HubSpot custom properties, include validation rules in the change request when the business needs consistent input. Specify the permitted values and exceptions, then verify where the selected rules apply in your HubSpot account. The decision about where to store data belongs in the register alongside the decision about who may change it.
HubSpot property governance starts before anyone opens the property editor. Compare the requested meaning with default properties and existing custom properties in your HubSpot CRM. A new label should represent a distinct requirement, not provide a second place for teams to store the same customer data.
HubSpot recommends checking default properties first. It also documents that a property's internal name and object type cannot be changed after creation, and that changing field type can invalidate existing values. Make those design decisions before approval and preserve an export before any approved type conversion. Create and edit HubSpot properties.
Consider what a user must record and how the information will be used. A free text field may suit a brief explanation. An agreed set of options may suit a classification used in reporting or workflow automation. A date has a different meaning from a note that happens to contain a date. Test realistic property values against the proposed field type.
Do not make the choice solely from the field type dropdown menu. Write the definition first, then have the authorized administrator verify which configuration supports it. If the request requires multiple selections, calculations or restricted access, record that requirement and check current availability before promising a solution.
Ask whether the fact belongs to a person, company, commercial opportunity or another defined business entity. For example, company size belongs to a different question from one person's role in a buying decision. Copying the same concept across contact and company records creates an additional synchronization decision that someone must own.
Use custom objects only after the data model and account eligibility have been evaluated. Do not create a new object or a collection of duplicate properties merely because the information is difficult to find on an existing record. First separate the storage requirement from the presentation problem.
Suppose a marketing team requests “Follow-up priority” for campaign planning. The requester initially wants to use website visits, lead source and a salesperson's judgment in one field. Those inputs describe different things. Ask which decision the new property will support before deciding whether to combine them.
An approved definition might instead say: “The campaign coordinator's reviewed priority for this specific outreach program.” The register would identify its object, permitted options, source information, owner and review date. It would explicitly state that the value is not the contact's lifecycle stage or a replacement for lead management status.
Then test an unknown value, an outdated decision and a contact who no longer qualifies for the program. Decide whether the field should be cleared, retained with context or changed through an approved process. The example is a design exercise, not a proposed live configuration.
Use property groups and clear descriptions to help authorized users find the right fields. Maintain a consistent register across sales, marketing and operations, with links to the relevant customer interactions or process documents where useful. A well-organized catalog should make duplicate properties easier to investigate, not merely move them into a less visible group.
Before creating properties, ask whether existing reports, marketing campaigns or automated workflows already depend on the same concept. Before editing properties, ask whether new values would change those outcomes. Active workflows deserve particular attention because a definition change may affect later records as well as the records being reviewed today.
Decide who may request a new property, who may configure it and who accepts the result. A request should include its purpose, proposed field type, expected property values and dependency review. Record rejected requests too, including the existing field the team agreed to use instead.
If someone asks how many custom properties the account allows, verify the current subscription limit rather than treating unused capacity as a reason to create more. HubSpot documents subscription-dependent limits. The governance question remains whether the business needs the field and can maintain its meaning.
A CRM administrator may implement a field without owning the business meaning. A sales leader may own the meaning without having permission to change the configuration. Keep those responsibilities separate in the register.
Name the role that approves the definition, the role that performs the change and the role that verifies the result. Define how conflicts between teams are resolved. Avoid a governance process in which every disagreement becomes another custom property.
If users need to understand the agreed definitions, include that work in HubSpot onboarding and training. A documented rule is more useful when the people entering and interpreting the data know where to find it.
Require a change request that explains the business reason, affected records, dependency review and proposed acceptance test. Include a mapping when existing values need to change, with exceptions separated for review.
Ask what happens to historical interpretation. If the definition changes, should old records retain the original meaning, be remapped under an approved rule or be distinguished in reporting? Have the business owner decide before execution.
For recurring symptoms, the guide to common HubSpot issues can provide context. The change record should still identify the exact field and process being corrected.
An apparently unused field deserves investigation before removal. We recommend an explicit review of known dependencies, data value and retention requirements, followed by an approved retirement plan.
| Review state | Decision to record | Evidence to retain |
|---|---|---|
| Candidate for retirement | Why the field may no longer be needed. | Business-owner review and an initial dependency inventory. |
| Replacement or transition | How affected users and processes will move, if necessary. | Mapping, approved changes and validation results. |
| Approved final action | What may be archived, removed or retained under current platform rules. | Current capability check, recovery assessment and explicit authorization. |
These are recommended governance states, not built-in HubSpot property statuses. Do not execute a destructive action from this table alone. Confirm current behavior and permissions, preserve the required evidence and obtain approval for the exact field and action.
First check whether an existing property answers the same business question. Compare its definition, object, allowed values and dependencies. Create a new field only when the distinct requirement and ownership are clear.
We recommend naming a business owner for the definition and a technical maintainer for the configuration. One person may fill both roles, but the register should show who decides meaning and who implements an approved change.
Do not make that the only test. Investigate historical reporting, workflows, forms, integrations and other dependencies first. Retain the retirement decision and approval, and execute only after the applicable checks pass.
Review the register when a new process, integration or reporting requirement arrives. Record the decision even when the answer is to use an existing field. That history helps the next person understand why the catalog looks the way it does.
If your team needs a starting point, use the HubSpot Portal Audit Scorecard to organize the issues, then discuss HubSpot operations and CRM architecture. We recommend a small set of clear rules that your team actually follows and maintains.
Product documentation checked August 30, 2026. Check current field behavior, permissions and recovery options before changing or retiring properties.