[object Object]

A rep loses a renewal because the customer success team had no visibility into the parent account’s open support escalations. The data was in HubSpot — under a different company record. Hierarchy was modeled as flat associations and reports could not roll up. Parent-child works in HubSpot, but the setup, the workflows, and the reports all need explicit thought before you turn it on.

Pick your model before you import

There are three common shapes:

  • Single legal entity, multiple offices — model as one company, use locations as a custom property
  • Holdco with operating subsidiaries — model as parent + children, one level deep
  • Conglomerate with global divisions — model as multi-level tree, parent has parent

HubSpot supports up to ten levels of nesting. Most teams need two or three. Decide before importing because rebuilding hierarchy on a populated portal takes weeks.

Direction matters

The parent property points up. A subsidiary’s Parent company field references the parent record. Get this backwards on import and you build a graph nobody can traverse cleanly.

Acme Corp (parent)
 ├─ Acme EMEA Ltd (parent_company = Acme Corp)
 ├─ Acme APAC Pte (parent_company = Acme Corp)
 └─ Acme Labs Inc (parent_company = Acme Corp)

When importing, populate the parent’s record ID into each child’s parent_company property. CSV import handles this if you stage parents first, capture their record IDs, then import children with a lookup column.

Reporting without double-counting

The classic pitfall: reporting on “all deals” returns deals on both parent and child records, inflating revenue. Use the Custom Report Builder with Company hierarchy as a join, then group by ultimate parent:

Object: Deal
Filter: Pipeline is Sales
Group by: Company > Ultimate parent name
Metric: Sum of Amount, where stage = Closed Won

Or maintain a calculated property account_family_revenue on the parent that sums children. Calculated properties refresh on demand and survive most edge cases.

Workflow re-enrollment across the hierarchy

A workflow filtering on Company is Customer enrolls each company independently. If you want the parent to enroll when any child becomes a customer, build the trigger on a custom event:

// Workflow custom code on child company stage change
const parentId = event.inputFields.parent_company_id;
if (!parentId) return;
const parent = await hsClient.crm.companies.basicApi.getById(parentId);
if (parent.properties.lifecyclestage !== "customer") {
  await hsClient.crm.companies.basicApi.update(parentId, {
    properties: { lifecyclestage: "customer" }
  });
}
return { outputFields: { parent_updated: true } };

Permissions roll downhill, not upward

A user with access to a parent company does not automatically see children. Each company is permission-scoped on its own. For account teams that need full-tree visibility, use a team assignment on every node, or a calculated account_team property that copies down from parent.

Contacts associated to multiple records

A buyer at a subsidiary often signs paper at the parent. Associate the contact to both with labeled associations: Decision maker on the parent, Daily user on the subsidiary. Reports filter on label so you do not double-count engagement.

What to do this week

Pull a list of your top 50 accounts, identify which need a hierarchy, and document the legal structure in a sheet before touching HubSpot. Pilot the model on one account family and validate that revenue, contacts, and tickets all roll up before scaling.

[object Object]
Share