Why You Cannot Find a HubSpot Deal by PO Number

A team did the right thing. Their deal names had drifted into a soup of client name, purchase order number and project code, so they created a proper PO Number property, moved the values into it, and cleaned the names up.

The next morning nobody could find anything. Typing a PO number into search returned nothing at all, and the data was sitting right there on the records.

The rule nobody reads until it bites

Custom properties are not searchable by default. Creating a property stores a value; it does not make that value findable by typing it.

HubSpot does let you fix this, and the fix has a hard ceiling: you can designate up to five custom searchable properties per object for global search, on contacts, companies, deals and tickets. Until a property is one of those five, its contents are invisible to the search bar.

The deal name, by contrast, is searchable out of the box. That is precisely why reference numbers migrate into record names across every CRM ever built: not because anyone designed it that way, but because the name is the field that search reaches.

So the cleanup that made the data model better made the working day worse, and the two facts are directly connected.

Two different searches, documented separately

Part of the confusion is that HubSpot has two search experiences and people describe them interchangeably.

Global search, the bar at the top left, spans assets: CRM records, activities, blog posts, website pages, marketing emails, segments, dashboards, workflows and campaigns. This is the one the five custom searchable property slots apply to.

The search bar on a CRM index page is a different feature with its own documentation. It works against certain default properties and behaves differently depending on the search term.

When somebody reports that "search is broken," establish which bar they were typing into before you change any settings. We have watched an hour go into the wrong one.

Spending the five slots

Five per object is a budget, and budgets deserve deliberate allocation rather than first-come-first-served.

The test is not importance, it is typing behaviour: would a human sitting at their desk actually type this value into a search bar to find a record?

Values that usually earn a slot:

• Purchase order and invoice numbers, because finance types them daily
• Account or customer reference numbers from an external system of record
• Project or job codes that appear on paperwork the team receives
• Serial or asset numbers, where the business runs on physical things
• The external system's record ID, when support staff work from tickets raised elsewhere

Values that usually should not:

• Anything nobody knows by heart. If the value has to be looked up somewhere else first, the person is already in the other system and can navigate from there.
• Long free-text fields. Search will match them and the results will be noise.
• Anything already covered by a default searchable property.

Run the allocation as a five-minute conversation with the people who use the portal, not as an architecture decision. Ask them what they type. The answers are usually unanimous and occasionally surprising.

When the slots are gone

Three fallbacks, in the order we reach for them.

A saved view filtered on the property. Slower than typing, entirely reliable, and it can be pinned for the team that needs it. This is the right answer for a value that a small group queries often and nobody else needs.

Reconsider the existing five. Slots get allocated during implementation and never revisited. A property that was going to be important in 2024 and never got filled in is holding a slot that finance would use daily.

Put it back in the name, deliberately. Unfashionable, and occasionally correct. If a reference number is the primary way humans identify a record, having it in the name is not sloppiness, it is design. The mistake is having it in the name by accident, formatted inconsistently, alongside four other things. A naming convention of company plus request type, applied consistently, is a legitimate structure.

The wrong answer is the one we see most: leave the value structured, unsearchable and undiscussed, and let the team quietly go back to a spreadsheet.

The habit worth taking from this

Before you move any value out of a searchable field into a structured one, ask a single question: does anyone find records by typing this?

It generalises well beyond PO numbers. The same trap catches teams tidying up ticket subjects, company names with trading-name suffixes, and contact records where somebody's known-as name gets replaced with their legal one. In every case the data model improves and the humans get slower.

The full version of the check, before a cleanup project touches anything:

1. List the values people currently search for. Ask them; do not infer it.
2. Confirm which of those live in searchable fields today.
3. Plan the slot allocation before the migration, not after somebody complains.
4. Migrate the values and set the searchable flags in the same change, so there is no window where the data is structured and unfindable.
5. Tell the team what changed, including where to look now.

Step four is the one that matters. The portal we opened this article with was in the bad window for a full working day.

Why this shows up most on inherited portals

Searchability is configuration that leaves no trace when it is missing. There is no error, no warning, and no report that lists properties people are failing to find. So the problem survives handovers indefinitely.

The pattern on a portal you have just taken over:

Symptoms without a ticket. Users have adapted. They keep a spreadsheet, or they navigate from the associated company every time, or they filter a view they built themselves two years ago. Nobody raises it because everybody has a workaround, and workarounds are invisible to an audit that only looks at the data.

The five slots are already spent, badly. Usually on properties chosen during implementation by whoever was configuring, not by whoever would be typing. We have found slots allocated to fields with a two percent fill rate while the identifier finance uses every day sits unsearchable.

Nobody knows the limit exists. Which means the client's own admin may have created twelve custom properties expecting all of them to be findable.

The diagnostic is a conversation rather than a query. Ask three people who use the portal daily: what do you type into the search bar, and what do you give up on and go looking for another way? The second half of that question is the one that finds it. People report things that error; they do not report things that quietly return nothing, because they assume that is how it works.

Then check what the five slots are currently spent on. In our portal audit work this sits in the same category as unused custom properties and stale lists: configuration that made sense once, was never revisited, and is now quietly costing people minutes every day.

One related limit, while you are in there

Record search is not the only place where a well-meaning cleanup meets an undocumented ceiling. Two others that come up in the same conversations:

Pinned notes. A record can carry exactly one pinned note. Teams that adopt pinning as a convention discover this when the second person tries to pin something and quietly unpins the first.

Dropdown length. Long option lists have no type-ahead, so a property with dozens of values becomes unusable at the point of entry regardless of how correct the taxonomy is. We wrote that one up separately in how to fix HubSpot's default industry property.

Both are the same category of problem as searchability: a limit that is invisible during design and obvious during use.

The bottom line

Custom properties are not searchable until you mark them so, and you get five per object. Tidying a reference number out of the deal name into a clean property will make it unfindable unless you spend one of those slots on it.

Decide the five with the people who type, set the flag in the same change as the migration, and use a saved view when the budget is spent.

If your team is inheriting client portals where the data model looks correct and the users have quietly gone back to spreadsheets, that gap is standard work for our white-label HubSpot support team, delivered under your brand.