Separate what they typed from what you report on

Someone fills in your form. In the job title field they type "VP Sales". The next person types "VP of Sales". The one after that types "vp sales, also run RevOps".

If all three wrote to the property you report on, you now have three rows in a report that should have one. Multiply by every free-text field and every month, and the reporting layer is unusable within a year. The data is all there. It is just not countable.

The pattern

Free-text and self-reported inputs write to a separate twin property, never to the native reporting property.

job_title_original_source        ->  native jobtitle, hs_role, hs_seniority
annual_revenue_self_reported     ->  native annual revenue

Then enrichment, a workflow, or a data-quality tool standardizes the raw value into the clean native property.

You keep both facts, which is the point. The twin holds exactly what the prospect said, which is useful context on a sales call and a genuine fallback when enrichment has nothing. The native property holds one clean value you can group by.

Which fields need this

Enrichment-backed fields, always: revenue, team size, industry, job title. The native property is owned by enrichment and is the source of truth. You can still ask on the form, but the form writes to the twin.

Dropdowns generally do not need it, because the values are already constrained. The split exists to absorb variation, and a dropdown has none.

Two related habits worth having

Do not ask for role and seniority directly. Let enrichment derive them from job title into the native Employment Role and Seniority properties. For decision authority, use the native Buying Role property, which is a multi-checkbox, curated in-form down to the options that matter to you: decision-maker, budget-holder, champion, end-user, researching. Curated native values still feed HubSpot's buying-committee features, so there is nothing to gain from a custom decision-role property.

Keep CRM labels short and report-facing. Property and option labels become index columns and report axes, so "Founder only" belongs at the CRM level. The friendly wording a human should read on the form, "Just me", is set as a per-form option-label override. Any field's labels can be curated in-form, including ones that look locked at the CRM level. Most people never find this, and end up choosing between a readable form and a readable report when they could have both.

Before you create anything

Scan the native properties and then the existing custom ones. Reuse beats recreate, every time, and most accounts already have more than the person building today knows about.

The cost of a duplicate property is not the property. It is the two years afterward where half your workflows read one and half read the other, and nobody can tell which is right.