Clay account hierarchies in HubSpot: parent and child companies that survive a conglomerate

Clay account hierarchies in HubSpot: Clay now resolves a company's whole parent and subsidiary tree from its own dataset, and HubSpot has had parent and child company associations for years. Nobody has written the part in between, which is the part that decides whether the tree is useful. This guide covers the model you set before touching data, the exact fields that bridge the two tools, the views and deal associations that make the hierarchy pay, and how to read a tree as a signal for account penetration or a group-wide deal.

Why do large accounts break in HubSpot?

Because they never arrive as one company. Clay's own documentation puts it plainly: "Large accounts rarely arrive in your data as a single company. They show up as business units, regional entities, and brands that all belong to the same parent."

In a CRM that shows up as four separate problems. Ownership: two reps working different arms of the same group without knowing it. Attribution: a deal at the German subsidiary sourced by a webinar the UK parent attended. Territory: a regional entity assigned by its own headquarters rather than the group's. And duplicates: the same group created five times under five brand names, each with two contacts.

HubSpot's parent and child company associations exist to fix this, but three limits shape everything that follows. Nothing rolls up: contacts, deals, activities and revenue stay on the child record, as Insycle's guide to child and parent company problems documents. Workflows cannot create associations. And there is no bulk assignment through import or workflow. So an external tool has to own the write, and the hierarchy has to be designed rather than switched on.

What does Clay's account hierarchy enrichment actually return?

The action is called "Enrich account hierarchies" and it is in beta. It is built from Clay's own company dataset rather than a third-party provider, which is why the recommended input is Clay's numeric company ID rather than a domain. Per Clay's documentation, you pick the scope on each run: parent companies as all levels, immediate parents only, or ultimate parent; and subsidiaries as all levels or immediate only.

The output is the bridge. Parent companies come back ordered from the top down, each with its level and its distance from the input company. Subsidiaries come back with an Immediate parent Clay company ID field. That field is the entire integration in one line, because it maps one to one onto a HubSpot child-to-parent association.

Three facts to plan around, all from the same documentation. Pricing is 2 data credits plus 1 action credit per run during beta, rising to 3 data credits on 1 December 2026, and runs that find no hierarchy data are refunded. Coverage is strongest for US and Global 2000 companies and most reliable above 50 employees, with weak coverage for startups and recent acquisitions. And the documentation says nothing about writing the tree into a CRM. That is where this guide starts.

There are two older routes worth knowing. Clay released a "Get Company Hierarchy" function on 20 April 2026 that maps the parent and subsidiary chain, and the HG Insights "Find company corporate structure" action returns group HQ, corporate parent flags and a children list. Both work. The native enrichment is the one to build on because it returns Clay IDs and levels, which is what the CRM write needs.

What do you decide before writing a single association?

The model. This is the step every team skips and the one that determines whether the hierarchy helps or hurts.

Depth. HubSpot nests several levels, but past two or three the reports become unreadable. The default we run: ultimate parent at the top, operating entities underneath, intermediate holding companies collapsed unless they buy or get billed separately. Clay's scope selector implements this directly. Parents set to ultimate plus immediate, subsidiaries set to immediate only, and "all levels" reserved for accounts that justify the credits.

What earns a company record. A legal entity that buys, gets billed, or is sold to. Brands, business units and regional desks that do not transact become a label on the entity they belong to. Without this rule a conglomerate becomes 300 company records with two contacts each.

The primary company rule. HubSpot logs a contact's activities against their primary company only. So the primary has to be the operating entity the person works at, never the group parent. Get this wrong and every call on the account logs against the holding company.

Ownership per level. Who owns the parent, who owns the children, and what happens when they disagree. The exercise we give every team is the agency with three offices: half owned by one rep, half by another, and a group contact who talks to both. Write the rule down before the data arrives, because the data will surface the conflict within a week.

Labels. HubSpot's built-in parent and child types are association type IDs 13 and 14 in the v4 API, per the associations documentation. On top of those you add user-defined labels, and a pair of companies can carry several at once: ultimate parent, billing entity, regional entity, brand. Views, routing and reports filter on these.

Which HubSpot properties bridge the two tools?

Four custom company properties, and the Clay company ID is the join key for all of them. Domain matching breaks on conglomerates: shared domains, country subdomains, brands with their own domain. Clay recommends its ID as the input for the same reason.

Two more properties earn their place once the tree is populated, and they are covered below: group_entities_total and group_penetration_pct on the ultimate parent.

How do you write the tree into HubSpot?

Two paths, chosen by scale.

Clay native, no code. The HubSpot integration in Clay has Look up object, Create object, Update object and Create association actions. The sequence per subsidiary row: look up by clay_company_id, falling back to domain; create the company only if it is missing and only if it passes the record rule; then Create association with the Parent Company type, from the child to the record whose Clay ID matches Immediate parent Clay company ID. This covers most teams and is the direct answer to syncing Clay data into HubSpot without creating junk records.

API or n8n for bulk and labels. The v4 batch endpoint creates thousands of associations in one call. The payload names the HubSpot-defined type for parent or child, and user-defined label IDs fetched from the labels endpoint for anything custom.

POST /crm/associations/2026-09/company/company/batch/create
{
  "inputs": [
    {
      "from": { "id": "<child company id>" },
      "to":   { "id": "<parent company id>" },
      "types": [
        { "associationCategory": "HUBSPOT_DEFINED", "associationTypeId": 14 },
        { "associationCategory": "USER_DEFINED",    "associationTypeId": "<label id for regional entity>" }
      ]
    }
  ]
}

Use this path when the list runs past a few thousand rows, or if the Clay action does not expose your custom labels, which is worth testing in your own workspace before you commit to one route.

The guardrails are identical on both paths. Look up before create. Never create a company from a hierarchy row that is outside ICP. Dedupe on Clay ID first and domain second. Stamp hierarchy_last_synced on every touched record.

How should deals and customer objects attach to the hierarchy?

This is where most implementations stop too early. A tree of companies with nothing hanging off it is a diagram.

Deals associate to the operating entity as the primary company, always. The entity that signs is the entity that owns the deal. Then add a secondary company association to the ultimate parent, labelled "group deal". HubSpot allows multiple company associations on a deal with distinct labels, and that second association is what lets you report on pipeline by group without breaking entity-level ownership.

The billing entity gets its own label. In a large group the entity on the invoice is often neither the buyer nor the parent. Label it, and let renewals live there. The renewal owner then sees one contract per billing entity rather than one per brand.

Contacts keep the operating entity as primary. A group procurement contact who spans three subsidiaries gets a secondary association to the parent with a label such as "group buyer". Their activities still log where they work.

Customer status lives on the parent as a computed property. If a team runs a custom Account object, the ultimate parent is the account and the subsidiaries are the entities inside it. If not, the parent record carries group_customer_status with a small set of values, prospect, customer, partner, derived from whether any child holds a closed-won deal. Either way, the question "are we in this group" gets one answer in one place.

Which views make the hierarchy usable?

Company views first, because that is where reps and managers live.

• Group parents. Filter hierarchy_level equals 0. Columns: owner, entity count, group pipeline, group ARR, penetration. This is the account list for anyone who sells to groups.
• Subsidiaries without an owner. Children whose owner is empty. New from the last sync, waiting for the ownership rule to run.
• Whitespace. Children with no open or won deal. The expansion list, filtered by parent so a rep sees whitespace inside their own groups.
• Cross-owner conflicts. Children whose owner differs from the parent's owner. Reviewed weekly, and the ownership rule decides which way it resolves.
• Changed since last sync. hierarchy_last_synced in the last 30 days and ultimate_parent_clay_id different from the previous value. The acquisition and divestment feed.

Deal views second. A "deals by group" view filtered on the group deal label, grouped by the parent association, gives group pipeline without a single spreadsheet. And on the parent record itself, customise the middle column so the child companies association table and the group properties sit above the timeline. A manager opening Unilever plc should see the tree and the numbers before any activity.

Reporting third, and this is where HubSpot's no-rollup limit bites. Nothing sums to the parent on its own. Build the group numbers one of two ways: a scheduled workflow that sums child deal amounts into the parent's group properties, or a custom report grouped by the parent company association. The report is honest immediately. The property is more convenient and needs maintenance. Most teams end up with both.

How do you tell if an account can be penetrated further?

Penetration is a ratio, and the tree gives you both halves of it. The denominator is the number of entities in the group that are inside ICP. The numerator is the number of those entities with a closed-won deal. Store both on the parent as group_entities_total and group_entities_customer, and compute group_penetration_pct.

What the ratio tells you, with the thresholds left as your own call rather than a number we would be inventing:

Two more reads worth building into the parent record. Velocity: how many child entities became customers in the last two quarters, which separates a group that is warming from one that bought once years ago. And whitespace by use case: which children match the pattern of the ones that already bought. That second one is the expansion list a rep can actually work, and it is a filter rather than a research project once the tree exists.

When does a hierarchy signal a global partnership?

When three things line up on the parent record at the same time.

Penetration has crossed whatever threshold your team set, and the wins are spread across at least two business units or countries rather than clustered in one. Buying has started to coordinate: the same procurement contact appears on deals at different entities, or a contract references the parent. And the group's own signals have shifted to the parent level: HQ visits to the pricing page, a group-level RFP, a mention of vendor consolidation in a call.

That combination means the group is about to make one decision about you whether you are in the room or not. The response is a group agreement: one master agreement at the ultimate parent, a named group owner, an executive sponsor at HQ, and the billing entities defined underneath it. The reverse case matters as much. High penetration with every entity on a separate contract is not a success metric, it is the setup for a procurement review that treats you as five small vendors instead of one strategic one.

The reason to encode this as a view rather than a gut feel is that the tree changes. Which brings us to reruns.

How do you keep the tree current?

Hierarchies change with every acquisition and divestment, and a tree written once is wrong within a year. Clay added device login to its CLI in the 3 August 2026 product roundup, which makes the enrichment a scheduled job rather than a table someone remembers to rerun. The pattern: monthly, for accounts with open pipeline or customer status, rerun the hierarchy enrichment, diff ultimate_parent_clay_id against the stored value, and route every change into the "changed since last sync" view for a human to confirm before any association or owner is rewritten.

Never auto-rewire ownership. A subsidiary changing parents is exactly the moment a rep needs to know, and exactly the wrong moment for a script to reassign the account silently.

Clay's MCP advanced search, from the 7 September roundup, covers the ad hoc version: asking for a company's tree from inside an agent session while prepping a call. The scheduled job keeps the CRM honest; the MCP call answers the question in the moment.

Where does this sit in a wider Clay and HubSpot setup?

The hierarchy is one of the three enrichment jobs described in our guide to Clay enrichment and lead routing for SaaS, the expansion job, and it depends on the data model decisions covered in HubSpot custom objects for RevOps. It also fixes the failure mode behind most lead-to-account matching problems, because a lead from any entity can now resolve to its group. Routing rules built on the tree are the same rules we describe in sales territory planning, with the group as the unit instead of the postcode.

If you want this built rather than described, it is the kind of work we run through our Clay agency service, and the HubSpot side, properties, labels, views and the association write, is what our HubSpot migration and architecture service covers.

FAQ

Does HubSpot roll child company revenue up to the parent automatically?

No. Contacts, deals, activities and revenue stay on the child record, and there is no data sync between parent and child. Group numbers have to be built with a scheduled workflow that sums child values into parent properties, or with a custom report grouped by the parent company association.

Can a HubSpot workflow create the parent and child associations for me?

No. Workflows cannot create associations, and there is no bulk assignment through import either. The write has to come from outside HubSpot, either Clay's Create association action or the v4 associations API through a tool such as n8n.

Should the deal sit on the subsidiary or the parent company?

On the subsidiary that signs, as the primary company. Add a secondary association to the ultimate parent with a "group deal" label so group pipeline reports work without breaking entity-level ownership.

How many levels of hierarchy should I model?

Two or three. HubSpot supports deeper nesting but reporting becomes unreadable past that point. Collapse intermediate holding companies unless they buy or are billed separately, and use Clay's scope selector to pull only the levels you will model.

What does Clay's account hierarchy enrichment cost?

During beta, 2 data credits plus 1 action credit per run, rising to 3 data credits on 1 December 2026, according to Clay's documentation. Runs that find no hierarchy data are refunded. Run parents-only across the whole list first and expand subsidiaries only for accounts inside ICP.

What if Clay has no hierarchy data for my accounts?

Coverage is strongest for US and Global 2000 companies with more than 50 employees and weak for startups and recent acquisitions. For gaps, fall back to the HG Insights corporate structure action or a Claygent research step, then feed the result into the same properties and association write.