HubSpot Company Hierarchies: How Parent, Child and Subsidiary Records Work

What a company hierarchy is in HubSpot

A company hierarchy is an association between two company records. You build it the same way you associate a contact to a deal. One company is marked as the parent. The other is marked as the child. HubSpot ships this pairing as a default association label. It renders as a small hierarchy card on both records once the link exists.

A parent company can have several children. A child company, through the default hierarchy label, sits under one parent. Some structures are more tangled than that: a franchise group with joint ventures, or a reseller network with overlapping ownership. Custom association labels handle those cases. You can create a label such as "Subsidiary of" or "Franchise location" and attach it to as many company pairs as the relationship needs. Unlike the default hierarchy label, a custom label is not limited to a single parent.

The distinction matters because teams often reach for the default parent/child pairing when what they have is a looser network. Get the label right at the start. Relabelling a hundred existing associations later is a bulk cleanup job, not a five-minute fix.

Why a flat company list breaks down

Without a hierarchy, every regional branch, subsidiary and franchise location is its own island. A rep working the head office account has no way to see that a subsidiary already has an open deal, so they pitch a service the group already bought. Your revenue reports count the parent and the children as unrelated small accounts instead of one account worth ten times more, so the group looks smaller than it is and gets less attention than it deserves.

Support tickets follow the same pattern. A contact from the subsidiary calls in, and the agent has no record of the parent account's history, its plan, or the fact that the head office negotiated a custom rate. The agent starts from zero on an account that has years of context sitting one company record away, just not connected to it.

Renewals and billing show the same gap. Finance renews the head office contract without knowing three subsidiaries signed on separately over the past year, on different terms, at different times. Nobody owns the full picture, because nothing in the CRM says these accounts belong together.

None of this is a data quality problem in the usual sense. The company records are accurate. They are just not talking to each other, and a flat list has no mechanism to make them.

How to set up parent, child and subsidiary records

Decide your labelling scheme before you associate a single company. Write down what counts as a true parent/child relationship for your business and what is closer to a partner or sibling relationship that needs a custom label instead. This is the step teams skip, and it is the one that causes the most rework.

Open the parent company record and find the hierarchy card. Search for the child company by name or domain and add it, choosing the parent/child label or a custom label you have already created. The link appears on both records immediately, the parent shows the child underneath it, and the child shows the parent above it.

For more than a handful of companies, associate them in bulk instead of one at a time. Import a spreadsheet with a column that maps each child company to its parent by name or domain, or use the associations API if the relationships already live in another system. Either path avoids the manual click-through that does not scale past a few dozen records.

Once the structure is built, audit it. Pull a list of every company with an association label and confirm the depth matches what you intended, because it is easy for a child company to end up parented to the wrong branch during a bulk import, and that mistake is invisible until someone runs a report that does not add up.

Common mistakes when building a hierarchy

Mixing the default label with custom labels for the same relationship is the most common mistake. Half the team associates subsidiaries as "child company", the other half creates a "Subsidiary of" label for the same relationship, and now a report that filters on one label misses records tagged with the other.

Skipping the audit step is close behind. A bulk import that maps children to parents by company name instead of domain will silently misfile any company whose name is not unique. Nobody notices until a group revenue report is short by one branch.

Building the hierarchy too deep causes the same reports it was meant to fix to become hard to read. A four or five level structure looks precise on paper, but the list filters and report groupings built on top of it turn into a maze nobody wants to maintain.

Treating the hierarchy as a substitute for permissions or territory rules is the last one. The association tells you which companies are related. It does not control who can see or edit them. That still lives in your teams, permission sets and territory rules, same as it did before you built the hierarchy.

Where HubSpot's rollup stops, and what that means for you

HubSpot does not automatically total deal value, revenue or any other number from child companies up to the parent record. The hierarchy tells you which companies are related. It does not do the maths for you.

If your team needs a single number for group revenue or open pipeline across a hierarchy, build it deliberately. Use a workflow that copies values up, a calculated property, or a custom report that groups by the association. Skip this step and the parent record's own numbers keep looking smaller than the group is. That undermines the reason you built the hierarchy in the first place.

Reporting on a hierarchy once it is built

Start with the company record itself. The hierarchy card is enough to answer "who else is part of this account" during a call, without a report at all.

For anything broader, filter lists and workflows on the association, such as every company with a parent company set, or every child of a specific parent. This is how you build a list of an entire account group in seconds instead of searching by name.

For the numbers, use the custom report builder to join companies to deals or contacts across the association, then group by parent. That report is what shows the head office a group-wide pipeline figure instead of ten disconnected small numbers, and it is usually the report that gets a hierarchy project approved in the first place.

Pin that report to a dashboard and leadership stops asking account managers to chase the group total by hand every quarter. The report updates itself as new children get associated, so the dashboard stays accurate without anyone maintaining a spreadsheet alongside the CRM.

When a hierarchy is worth building, and when it is not

A hierarchy earns its keep for franchise networks, holding companies with subsidiaries, reseller or channel structures, and agencies managing several client brands under one commercial relationship. In each case, the parent and children are genuinely one account for sales, support or reporting purposes, and the group view changes how your team works the account.

It is not worth building for basic segmentation. If you are grouping companies by industry, region or size, a property and a list do that job without the maintenance overhead of an association. Save the hierarchy for relationships that are structurally true, not for categories you could filter on instead. Keep the structure shallow, too. Two or three levels deep stays usable; go further and the reports built on top of it get harder to read than the flat list you started with.

Test the fit before you commit the whole portal to it. Build the hierarchy for one account group first, run your usual reports against it, and confirm the reporting and permissions behave the way your team expects. A small pilot catches a wrong labelling decision while it still costs an afternoon to fix, not a full re-import.

If your portal has grown past a single flat company list and the group relationships live in someone's memory instead of the CRM, get in touch and we will map the hierarchy that matches how your business is structured.

Related.

Common questions.