Should That Property Live on the Deal or the Company?

A client asked me to add a Company Type property to their Deal record.

It was a reasonable request. Their reps wanted to see the company's type without clicking through to the Company record, and their reporting needed it on the Deal. Easy enough — create the property, capture the value, push it back to the Company with a workflow. Twenty minutes of work.

I said no. Or more precisely, I said "we can, but here's what happens in six months."

This comes up in almost every HubSpot implementation I run, and it's worth understanding the reasoning — because the answer isn't a rule you memorize. It's a question you ask.

The question: what does this property describe?

HubSpot's object model isn't arbitrary. Each object answers a different question about your business:

• Contact — what's true about a person
• Company — what's true about an organization
• Deal — what's true about a specific transaction

Company Type describes an organization. It's true whether there's a deal open or not. It's still true after the deal closes, and it's true across all four deals you might run with that company over the next three years.

Put it on the Deal and you've stored an organizational fact in a transactional container. The data isn't wrong, exactly. It's just in a place that can't maintain it.

Why "we'll sync it back" doesn't solve the problem

The usual fix is a workflow: capture the value on the Deal, copy it to the Company. Now both records have it. Problem solved.

Except now you have two properties holding the same fact, and only one of them is right.

When Company Type changes — the company gets acquired, changes segments, moves upmarket — somebody updates the Company record. That's the correct move. But the three closed deals from last year still carry the old value, frozen at the moment they were created. Your historical reporting now says something that isn't true.

Or it changes on the Company and nobody thinks to check whether an open deal needs updating too. Now your active pipeline is reporting stale segmentation, and the person building the forecast has no idea.

Either way you've created a maintenance obligation that lives in someone's memory rather than in the system. That's the real cost. Not the twenty minutes to build it — the ongoing requirement that everyone remembers where the "real" value lives.

What to do instead

Three options, in the order I'd try them.

Use the association. HubSpot lets you pull associated Company properties into Deal views, list filters, and most reports without duplicating the data. The rep gets visibility, the reporting works, and there's exactly one place the value lives. This solves the request most of the time, and it's the option people skip because it isn't obvious.

Put it in the Deal record sidebar. If reps need to see it while working the deal, customize the record sidebar to surface associated Company properties. They see it without leaving the Deal. No new property, no sync, no drift.

Create the Deal property deliberately — if it's genuinely a snapshot. Sometimes you actually want the value frozen at deal creation. "What segment were they in when we sold to them" is a real business question, and it's different from "what segment are they in now." If that's what you need, build it on purpose, name it so the intent is obvious (Company Type at Close, not Company Type), and document why. The problem was never the Deal property. It was the Deal property pretending to be the current truth.

The test I use

Before adding any property, one question: if this value changes tomorrow, where does someone go to change it — and will every place it appears update?

If the answer is "one place, and yes," you're fine. If the answer involves a workflow, a reminder, or a person remembering something, you've just built maintenance debt into a system that's supposed to reduce it.

This is what separates a HubSpot portal that holds up at year three from one that quietly rots. Not the sophistication of the build. The discipline about where things live.

Why this matters more than it sounds like it should

Every one of these decisions is small. Nobody's implementation fails because of one misplaced property.

They fail because forty of these decisions got made the fast way, and now nobody can explain why the same information appears in three places with three different values. The reports stop matching. The team stops trusting the reports. And somebody starts keeping a spreadsheet on the side, because at least the spreadsheet is theirs.

The best HubSpot implementation isn't the one that makes today's request easiest. It's the one that makes tomorrow's CRM easier to live with.

Not sure what's already drifted?

The RevOps Foundation Scorecard takes about five minutes and gives you an honest read on your CRM structure, data quality, alignment, reporting, and AI readiness — including the kind of accumulated decisions that make a portal hard to trust.

Take the RevOps Foundation Scorecard →

Already know something's off and want a second set of eyes? Schedule a call and we'll look at your portal together.