How to Fix HubSpot's Default Industry Property

HubSpot's default Industry property on the company object carries roughly 150 predefined options. They cannot be deleted. Most default properties and their options cannot be edited either. You can add your own values, which makes the list longer.

That is the whole problem. Every client who has ever tried to standardise industry reporting in HubSpot has run into it, and the two instinctive responses, tidying the list or making everyone pick carefully, are both dead ends.

Why the length actually matters

It is tempting to shrug at a long dropdown. Three reasons not to.

Nobody scrolls to the right answer. HubSpot's dropdown fields have no type-ahead search. A rep looking for "Management Consulting" scrolls until they find something close enough and picks it. On a list this long, close enough wins every time.

The resulting data cannot be segmented. Fifty companies in the same real-world sector spread across nine plausible options is not a segment. It is nine segments of five or six, each too small to act on, and no report will reveal that the split is an artefact of the picker rather than of the market.

It gets worse when you add to it. The natural response to "none of these fit" is to add an option. That makes the list longer, which makes the scrolling problem worse, which makes the next person more likely to pick something approximate. Portals accumulate industry values the way they accumulate everything else.

We audited a portal with 648 custom properties, 82 of them completely unused, down from over 900 before a purge of 300. Long enumerated lists are the same pathology at property-value scale, and they are less visible because nobody counts the options inside a property.

What to build instead

Leave the default alone. Build a custom industry property. Give it the values the business actually acts on.

The design, in four steps:

1. Derive the values from behaviour, not from taxonomy. Ask what would change if a company were in this industry rather than that one. A different message, a different owner, a different pipeline, a different service? If nothing changes, it is not a distinct value. Most businesses land on eight to fifteen. If a client insists on forty, ask them to name the different treatment each one receives, and the list shortens in the room.

2. Add an Other option with a dependent free-text field. The free-text field only appears when Other is selected. This is the part people skip, and it is what stops the shortened list from destroying information. A rep who genuinely cannot classify a company types what it is instead of picking something wrong.

3. Review the Other entries monthly. Anything appearing repeatedly becomes a real option, and you backfill the records that used the free-text version. This is a ten minute recurring task and it is the mechanism that keeps the property honest over years. Without the review, Other becomes a landfill and you have rebuilt the original problem with fewer steps.

4. Populate the new property from the old one where you can. A mapping from the roughly 150 defaults to your fifteen is mechanical for most values and a judgment call for a handful. Do it as a one-time import, and remember there is no append in HubSpot imports, so export first.

Why you keep the default property

Two reasons not to try to purge it, beyond the fact that you cannot.

Enrichment tools and integrations write to it. Data enrichment vendors, HubSpot's own enrichment, and most third-party integrations map to the default Industry field because it is the one they can rely on existing. Your custom property is invisible to them unless somebody configures it. Delete or ignore the default and you lose that inbound data.

We audited one portal running three enrichment vendors writing contradictory values into the same fields, with one vendor installed twice. That is worth finding, and you find it by watching what writes to the default properties, not by pretending they are not there.

It is a fallback when your shortlist is wrong. Six months in, when the business enters a new market, the default value on the record is the raw material for reclassifying.

So the model is: the default property is a data field, and your custom property is the operational one. Both populated, only one maintained by humans.

The general rule this is a case of

Industry is the most common example, but the underlying principle applies to every enumerated property in the portal:

A dropdown option should exist because something differs when it is selected. Not because the value exists in the world.

Two working rules that follow.

Delete any option with zero records. Cheapest cleanup available on any portal. Go through the enumerated properties, check the record count per value, and remove the empties. It costs nothing, it breaks nothing, and it shortens the lists people scroll every day. On portal audits we run this as a standard pass, and it consistently removes more options than anyone expected.

Model long lists as parent and child. When a taxonomy genuinely needs 150 values, one dropdown is the wrong shape. Use a short parent dropdown and a dependent child field whose options change with the parent. The user makes two short choices instead of one long one, and the data comes back cleaner because both choices were deliberate.

The other properties with the same disease

Industry is the loudest case. Once you know the shape, you find it across the portal, and the same fix applies to all of them.

Lead source and original source detail. The classic sprawl. Every campaign that ever ran added a value, nobody removed any, and the resulting list cannot be reported on because "Webinar," "webinar," "Webinar 2024" and "Web-inar" are four values. Attribution reporting built on this is decorative.

Deal type. Usually starts with two sensible values and grows a tail of one-off entries created during specific deals. Ask which values change the pipeline, the approval path or the pricing. Anything that changes nothing is a note, not a property value.

Country and region. Frequently free text where it should be a controlled list, or a controlled list where the same country appears as "UK," "United Kingdom" and "GB." This one is worth fixing early because territory routing and tax logic both depend on it, and both fail silently on a mismatch.

Job title and seniority. Job title is genuinely free text and should stay that way. The mistake is trying to segment on it directly. Add a controlled seniority or persona property alongside it, populated by workflow from title keywords, and segment on that.

Anything an integration writes. Enrichment vendors, form tools and ad platforms all write values, and their vocabularies are not yours. If two enrichment tools write to the same property, they will disagree, and the record will hold whichever wrote last. We audited a portal running three enrichment vendors with contradictory data, one of them installed twice.

The audit pass is the same in every case and takes an hour for a whole portal: export the value counts for every enumerated property, sort ascending, and look at the tail. Values with zero records go. Values with one or two records are usually typos or one-off entries and should be merged. Whatever survives is a candidate for the shortlist.

The order of operations on a live portal

Enumerated property changes touch reports, lists and workflows, so sequence matters:

1. Inventory what reads the current value. Lists, reports, workflow enrollment criteria, integration mappings, form fields. Every one of these changes meaning when the property changes.
2. Export the current values for every record. This is your rollback.
3. Create the new property and populate it by import, without changing anything that reads the old one yet.
4. Reconcile. Check the record counts per value against what you expected, and open ten records by hand.
5. Repoint the readers, one class at a time: reports, then lists, then workflows.
6. Update the forms last, because that is the change external visitors see.
7. Leave the old property in place, unhidden, still receiving enrichment data.

The temptation is to do steps three and five together. Resist it: if the counts are wrong you want to discover that while nothing downstream depends on the new property.

What to tell the client

This conversation goes better when it is framed as a reporting decision rather than a data cleanup, because that is what it is.

The sentence that lands: "Right now your companies are spread across dozens of industry values, so no industry report has enough records in it to act on. We can give you twelve values you actually run the business by, keep the raw data underneath, and have a monthly review that catches anything we got wrong."

Two objections to expect. The first is that a shorter list loses detail: the dependent Other field is the answer, and it is worth showing them. The second is that somebody will pick wrong anyway: true, and a twelve-item list is dramatically easier to pick correctly from than a 150-item one with no search.

The bottom line

HubSpot's default Industry property is roughly 150 fixed options you cannot delete, in a dropdown with no type-ahead. It is a data field, not an operational one. Build a custom property holding only the values that change what you do, pair it with a dependent free-text Other, review those entries monthly, and leave the default in place for enrichment and integrations.

The same test applies to every dropdown in the portal: an option earns its place by changing an outcome, not by existing.

If you are inheriting client portals where nobody can report on segment, property architecture is one of the dimensions our white-label HubSpot audits score, and the remediation runs under your brand. Our guide to conducting a HubSpot contact audit covers the record-level side of the same cleanup.