How to Model Customer Hierarchies for a B2B CRM
How to model customer hierarchies in a B2B CRM: parent pointers, typed relationships, rollups and inherited permissions.
To model customer hierarchies for a B2B CRM, keep every company in one account table where each record points to a parent account, then add typed relationship records for the cases a single parent cannot express: who pays, who buys, and who can see what. Settle two questions before you write code, how deep the tree goes and what happens when a branch moves, because those answers decide the storage pattern, the rollup logic and the permission rules.
What is a customer hierarchy in a B2B CRM?
A customer hierarchy is a parent-child structure over company records, where a headquarters account sits above regional, divisional, or site accounts. It exists so revenue and permissions can be rolled up to a group instead of tracked account by account.
A CRM, short for customer relationship management system, is the system of record for companies, the people at them, deals in progress and activity history. The account is the record for one company. A hierarchy is the set of parent-child links between accounts. A rollup is a total calculated from child records, such as all open pipeline under a group account.
Three structures get drawn over the same accounts, and conflating them is the most common modelling mistake:
- Ownership: which legal entity owns which. Used for contracts, compliance and revenue recognition.
- Billing: who actually pays the invoice. A subsidiary can place the order while the parent settles it, and one parent pointer cannot hold both facts.
- Buying and access: who influences the purchase and who may see the data. Procurement sits at group level, budget at division level, daily usage at a site.
A single parent field models the first case well and the other two badly. Give each relationship its own record with a type, a start date and an end date, so history survives a reorganisation.
How deep should a customer hierarchy go?
Most B2B hierarchies work at three to five levels: group, region or division, legal entity, site. Beyond roughly six levels, recursive queries and permission checks slow down, and users stop trusting the numbers they see.
Set a hard depth limit, say eight levels, and validate it when an account is saved. A depth value stored on each account makes branch queries cheaper, because the application can filter without walking the whole chain. Deep trees are not wrong, they are expensive, and the cost appears as slow reports rather than as a bigger build estimate.
How should you store a hierarchy in the database?
Store each account as one row with a parent identifier, then pick a read pattern for branch queries: walk the parent pointer, use a closure table of ancestor pairs, or store a materialized path.
Definitions first. A parent identifier is a foreign key, a column whose value must match an existing account's identifier. A recursive query is a database query that calls itself to follow the chain one level at a time. A closure table is a second table holding one row for every ancestor and descendant pair. A materialized path is a text column containing the identifiers of every ancestor, written in order.
| Storage pattern | Rows added per account | Reading a full branch | Moving a subtree | Fits |
|---|---|---|---|---|
| Parent pointer (adjacency list) | None, a single column | One recursive query, cost grows with depth | One row update | Trees up to roughly five levels |
| Closure table | One per ancestor, so a five level branch can add ten to fifteen | One indexed join | Delete and reinsert pairs, hundreds of rows on a large branch | Deep trees with heavy reporting |
| Materialized path | None, one text column | Prefix match on the path | Rewrite the path on every descendant | Read heavy trees that rarely move |
The trade is always the same: you pay either at read time or at write time. If accounts move once a quarter, pay at write time. If they move weekly, keep the parent pointer and cache your rollups instead.
If you would rather not build that layer from scratch, a custom CRM can be scoped around the depth, relationship types and permission rules your business actually uses.
How do you calculate rollups on a hierarchy?
A rollup totals child records up the tree, such as open pipeline for a group account. Compute it on a schedule into a summary table rather than recalculating it live on every page load.
Decide four things early:
- What rolls up. Pipeline value, contract value, seat count and support ticket volume often need different rules.
- How often. Nightly suits most reporting, while deals and invoices usually need near real time behaviour.
- Whether mid levels see subtotals. A regional manager usually wants the region plus its children, not the group figure.
- What happens mid period. If an account moves in March, decide whether March revenue stays with the old parent.
How do you handle access control across a hierarchy?
Access is inherited down a hierarchy when a user assigned to a group account can see every account beneath it. Store grants in a separate table so one person can hold different roles at different levels.
Access control, often called role based access control or RBAC, means permissions attach to a role and the role attaches to a person, rather than to the person directly. Three rules keep inheritance predictable:
- Inheritance flows down and never up. A user at a site account should not see the group.
- An explicit denial beats an inherited grant, and the denial must be visible in the admin screen.
- Reparenting triggers a permission recompute. On a branch of a few thousand accounts that can take minutes to hours, so queue it rather than blocking the save.
How do you keep hierarchy data clean?
Hierarchy data degrades through reorganisation, acquisitions and manual entry, so the model needs guards. Orphan accounts, cycles between parents, and two records for the same legal entity are the three failures to defend against.
An orphan is an account whose parent no longer exists. A cycle is a loop where a record ends up as its own ancestor, which will hang a recursive query. Build these checks in:
- Reject any save that would create a cycle, and test it with an account that already has children.
- Never hard delete an account that has children. Archive it and reassign its children in one transaction.
- Require a reason code and an effective date on every reparent, and keep the previous parent in a history table.
- Run a monthly review that lists parents with a single child, accounts sitting more than six levels deep, and parents whose children span more than one country.
When should you skip the hierarchy entirely?
Keep accounts flat when fewer than roughly 10% of your accounts have a parent and deals are closed account by account. A segment field, meaning a label such as enterprise or mid market, plus a parent name for display handles most of those cases cheaply.
Hierarchies are worth building when contracts, reporting or permissions genuinely need to roll up. If only sales operations asks for the tree and nobody acts on the rolled numbers, you are paying for structure that produces no decisions.
Retrofitting a hierarchy into a CRM built on flat accounts usually costs two to three times the original build, because every report, permission rule and integration has to be rechecked. Depth and move rules are cheap to decide on paper and expensive to change later.
Frequently asked questions
What is a parent account in a B2B CRM?
A parent account is the record that sits above other accounts and represents the group, headquarters or legal entity that owns them. Child accounts hold the sites, subsidiaries or divisions, and most CRM data models allow a child to have only one parent at a time.
Can a CRM account have more than one parent?
Most CRM data models allow exactly one parent per account, which keeps recursive queries and permission inheritance simple. If billing, ownership and buying relationships need to differ, model the extra ones as relationship records with a type instead of adding a second parent field.
How do you move an account to a different parent?
Reparenting should be one transaction that updates the parent, records the previous parent in a history table and queues a permission recompute. On a branch of a few thousand accounts the recompute can take minutes to hours, so it must not block the save.
How many levels should a B2B customer hierarchy have?
Three to five levels covers most B2B structures: group, division, legal entity and site. Beyond roughly six levels, branch queries and permission checks get slower, and users tend to distrust the rolled up numbers.