Modeling 5,000 Physical Assets in HubSpot

"Show me every location with an open deal for this carrier."

That's a one-sentence request from a sales leader, and out of the box, HubSpot can't answer it. We found this out designing an architecture for a commercial real estate company with roughly 5,000 locations, where every deal is an opportunity on a specific physical location. Their sales team needs two views of the same world at once: customer-centric (everything happening with one business) and asset-centric (everything happening on one location). Getting both out of HubSpot took three design decisions worth writing down, because they apply to anyone selling against physical assets: sites, machines, properties, vessels, installed equipment.

Pick the object for the record count you'll have in five years

HubSpot ships native objects that look tempting for asset modeling. We rejected the native option here for a blunt reason: record limits. The native object capped out lower than the custom object limit, and 5,000 locations today isn't 5,000 forever, especially once you add historical records. Nobody wants to re-platform their core object in year three because they saved a week in year one. Check the ceilings first; they're buried in documentation nobody reads until it's too late.

Associations don't report the way you assume they do

Here's the gap that surprises people. You can associate a custom Site object with deals all day, but HubSpot's native filtering can't cleanly answer cross-object questions like "all sites with an open deal for carrier X" in an index view. The associations exist; the reporting on them is weak.

The workaround is denormalization, which sounds like a database sin and works beautifully: a workflow writes carrier names into multi-select properties directly on the Site record. Three properties did the job: which carriers are live on the site, which have open opportunities, and which were lost. Suddenly every question the sales leader asked becomes a filterable view, no custom reporting gymnastics required. Yes, you're duplicating data the associations already hold. That's the point. You're trading purity for usability, and usability is what gets adopted.

One deal, many sites, mixed outcomes

The messiest real-world wrinkle: a single opportunity can span multiple locations, and the customer can say yes to some and no to others. One deal record with one stage can't express that. Association labels can: label each site's relationship to the deal, and you keep one commercial negotiation as one deal while still tracking per-site outcomes.

None of this is HubSpot bashing. It's the opposite. The platform handled an enterprise asset model fine, but only because someone made deliberate choices about objects, limits, and reporting before the first record was created. Custom objects at this scale aren't a data entry decision. They're an architecture decision.

Selling against physical assets and wondering whether HubSpot can hold your model? The honest answer is usually yes, with design. That design conversation is the one to have before you buy, not after.