Every organization with subsidiaries, franchises, or affiliated entities eventually asks the same Salesforce question: should we build out a full parent-child account hierarchy, or keep account structure flat and handle complexity another way? Get this decision wrong and you either drown admins in branch-level maintenance nobody needed, or you lose the enterprise-wide visibility a sales or service leader actually asked for.
This guide covers when a deep account hierarchy earns its keep, when a flatter structure with a lightweight parent record works better, and how to model relationships — like advisor or account teams — that don't fit neatly into a hierarchy at all.
A Salesforce account hierarchy links related accounts under a parent record so you can roll up opportunities, cases, and reporting across a corporate family. It matters most for organizations selling into or servicing complex, multi-entity customers — franchises, holding companies, or firms with multiple subsidiaries or regulatory identifiers. Build hierarchies deep only when you need visibility or access control at that level; for many organizations, a minimally populated parent record with a distinct record type, linking existing accounts beneath it, delivers roll-up reporting without the maintenance burden of branch-level detail. Vantage Point designs this data model through its Salesforce implementation and advisory services.
An account hierarchy links accounts through the standard Parent Account field, letting you view a related list of child accounts on any parent record and roll up totals — like open opportunities or cases — across the whole family. It's the standard mechanism for representing corporate structures: a holding company with subsidiaries, a franchisor with franchisees, or a firm with multiple branches or registered identifiers.
Salesforce's own documentation on account hierarchies notes that for companies with multiple office locations, an Account Site field can distinguish locations without necessarily requiring a full hierarchy — a reminder that hierarchy is one tool among several, not the default answer to every multi-location scenario.
Account hierarchies earn their maintenance cost when at least one of these is true:
None of these require branch-level detail by default. A hierarchy that stops at the legal-entity or CRD/identifier level, without extending down to individual offices or teams, delivers the rollup and reporting benefit without the ongoing maintenance of tracking every branch as its own account.
If your organization's visibility model is already broadly open — most users can see most accounts regardless of ownership — the access-control rationale for a deep hierarchy doesn't apply. In that situation, a minimally populated parent account record, using a distinct record type so it's clearly not an operating entity, linking existing subsidiary or branch accounts beneath it, is usually enough. It gives you the rollup reporting without asking anyone to maintain branch-level nodes that exist only to satisfy the tree structure.
The trigger for adding depth later should be a specific, named reporting or access need — not a general instinct that "more structure is more correct."
| Concept | What it controls | Typical use |
|---|---|---|
| Account hierarchy | Groups related account records for rollup and reporting | Enterprise pipeline and case visibility across a corporate family |
| Role hierarchy | Controls which users can see which records, based on org chart and sharing rules | Manager visibility into subordinates' records; territory-based access |
These two hierarchies are frequently confused because both use tree structures and both can affect what a user sees, but they solve different problems and are configured independently. A deep account hierarchy does not automatically grant or restrict user access — that's the role hierarchy and sharing model's job.
Some relationships genuinely don't fit inside an account hierarchy — most commonly, a team of people (an advisor group, a regional sales pod, a joint account team) whose members are spread across several related but distinct accounts. Forcing that relationship into the account tree usually produces an awkward structure that satisfies neither the org chart nor the reporting need.
A cleaner pattern is a custom object representing the team itself, with a junction object connecting team records to the contacts or accounts that belong to it. This lets you report on team-level activity and opportunity value without pretending the team is itself a parent account. It's particularly relevant for organizations where the largest revenue opportunities are associated with a team's collective book of business rather than any single account.
A few patterns recur across account hierarchy projects, regardless of industry:
Most of these mistakes share a root cause: building structure before defining the specific question it needs to answer. Reversing that order — question first, structure second — avoids nearly all of them.
Vantage Point designs Salesforce data models for organizations with complex account structures — multi-entity firms, regulated industries, and businesses with account teams that cross traditional account boundaries. Our Salesforce implementation and advisory services start with the reporting and access questions your teams actually need answered, then build the shallowest structure that reliably answers them, backed by our managed services and ongoing support for the maintenance that follows. We are employee-owned, with 400+ engagements for 150+ clients, a 4.71/5.0 average engagement rating, and 95% client retention — senior consultants only, no junior handoffs; the experts you meet are the experts who deliver.
Vantage Point can review your current account structure against your actual reporting and access needs and recommend the simplest model that works. Talk to Vantage Point about your Salesforce data model.
Not necessarily. If your visibility model is already broadly open and you mainly need rollup reporting, a minimally populated parent account record linking existing accounts beneath it is often enough, without maintaining a branch-level account for every location.
An account hierarchy groups related account records for reporting rollups. A role hierarchy controls which users can see which records based on the org chart and sharing rules. They're configured independently and solve different problems, even though both use tree structures.
When you need enterprise-wide pipeline or case rollups across a corporate family, when access control genuinely depends on the account structure, or when net change (expansion in one subsidiary offsetting contraction in another) needs to show correctly at the parent level.
Use a custom object to represent the team itself, connected to contacts or accounts through a junction object. This avoids forcing a cross-account relationship into the account hierarchy, where it doesn't fit cleanly.
Use a distinct record type for parent records created solely to enable rollups, rather than reusing an operating-entity record type. This keeps the parent record from being mistaken for an active account with its own activity.
No. Account hierarchy affects reporting rollups and related lists, not record-level access. Sharing and visibility are controlled separately through the role hierarchy and sharing rules.