Salesforce Account Hierarchy: Setup, Parent-Child & Normalization

March 2026 · 12 min read

Your sales team has created separate Account records for each: "Acme Industries," "Acme Healthcare Solutions," and "Acme Digital." Three different owners. Three separate pipelines.

This is what happens when you don't have a Salesforce account hierarchy in place. The data exists. The relationships don't. And without relationships, you can't see the full picture of your customer, your pipeline, or your revenue.

Setting up account hierarchies is mechanically straightforward; doing it well requires planning. This guide covers how to structure parent-child relationships, when to use D-U-N-S numbers, how company name normalization fits in, and how to report on hierarchies once they're built.

How Do Parent-Child Accounts Work in Salesforce?

Salesforce has a native ParentId field on the Account object. It's a lookup to another Account record. That's all a hierarchy is: Account records linked together through this field.

Parent Account: The company one level up. "Acme Healthcare Solutions" has Parent Account set to "Acme Industries."

Child Account: Any account that points to another account as its parent. "Acme Digital" is a child of "Acme Industries."

Ultimate Parent: The top of the chain. The account with no parent of its own. In a hierarchy like Alphabet > Google > Google Cloud, Alphabet is the Ultimate Parent.

Salesforce displays these relationships in the Account Hierarchy view, which you can access from any Account record by clicking "View Account Hierarchy" in the action menu. It shows the full tree: parent, siblings, and children.

When to create child accounts vs. merge

A related company belongs as a child account only when that structure matches the buying entity, reporting needs, and ownership evidence.

Scenario	Recommendation
You sell to divisions separately (different buyers, different agreements)	Create child accounts under a parent
Different office locations for the same company	Create child accounts if each location has its own buying authority
Same company entered twice with different name variations	Merge, don't create a hierarchy
Acquired company still operating independently	Child account under the acquiring company
Franchise locations	Child accounts if you sell to individual franchisees

The key question: do these entities buy independently? If yes, separate accounts in a hierarchy. If no, merge them.

Setting Up Your Hierarchy

Step 1: Define your hierarchy model

Before you start linking accounts, decide on your structure. Most B2B organizations use one of these models:

Two-level (Parent/Child): Simple. Works for companies where you care about the corporate parent and individual operating entities. Example: "Microsoft" (parent) > "LinkedIn" (child), "GitHub" (child).

Three-level (Ultimate Parent/Region or Division/Operating Entity): Common in enterprise sales. Example: "Alphabet" > "Google" > "Google Cloud Platform." The middle tier represents a business unit or geographic region.

Four-level (Global Parent/Region/Country/Local Entity): Needed for global enterprises with complex structures. Example: "Siemens AG" > "Siemens North America" > "Siemens USA" > "Siemens Healthineers USA." Only go this deep if your sales team sells at these different levels.

Keep it simple. Each additional level adds maintenance overhead. If your reps rarely sell to regional entities separately, don't create regional accounts just because the corporate structure exists. Match your hierarchy to your go-to-market rather than to the org chart.

Step 2: Create custom fields

The native ParentId field handles the direct link, but you'll want additional fields for reporting and automation:

Ultimate_Parent_Account__c (Lookup to Account): Points to the top of the hierarchy chain. Critical for roll-up reporting.
Hierarchy_Level__c (Picklist: Ultimate Parent / Parent / Child): Makes filtering and reporting easier.
DUNS_Number__c (Text, 9): If using D&B data for hierarchy.
Global_Ultimate_DUNS__c (Text, 9): The D-U-N-S of the ultimate parent entity.

Step 3: Populate the Ultimate Parent field

Salesforce doesn't automatically calculate the Ultimate Parent. You need to build that logic. Three approaches:

Flow (no-code): Create a Record-Triggered Flow on Account that fires on create and update. When ParentId changes, walk up the hierarchy by querying the parent's parent until you find an Account where ParentId is null. Set that as Ultimate_Parent_Account__c. This works but can hit governor limits on deep hierarchies.

Apex trigger (code): More efficient for large orgs. Write a trigger that recursively traverses the hierarchy on insert/update of ParentId. Handle bulkification properly since a mass update could fire this for thousands of records.

Enrichment tool: Services like Dun & Bradstreet, ZoomInfo, or Clearbit can provide hierarchy data that includes the ultimate parent. Import their hierarchy and let the data source handle the linking. This is often the fastest approach for initial setup.

Step 4: Link existing accounts

If you already have accounts that should be linked, you'll need to identify the relationships and populate ParentId in bulk.

Export Accounts with Id, Name, Website, and any existing hierarchy fields.
Identify parent-child relationships. Group by domain/website to find accounts that belong to the same company. Use normalized company names to catch variations.
Build a mapping file. Create a CSV with the child Account Id and the parent Account Id.
Import via Data Loader. Update the ParentId field using your mapping file.
Run your Ultimate Parent automation to populate the Ultimate Parent field on affected records.

Should You Use D-U-N-S Numbers for Hierarchy?

Yes, if you sell into enterprises with subsidiaries and international entities. D-U-N-S numbers from Dun & Bradstreet are nine-digit identifiers assigned to each business entity worldwide. Each entity gets its own number, and D&B tracks the relationships between them: which entities are subsidiaries, branches, divisions, and headquarters.

This solves the hardest part of hierarchy management: figuring out which companies are related. When "Acme Healthcare Solutions" and "Acme Digital" both have D-U-N-S numbers that link to the same Global Ultimate, you know they belong together without guessing.

How to use D-U-N-S in Salesforce

Get D&B data. Through Salesforce's native Data.com (if available in your edition), D&B Direct, or a third-party enrichment provider that includes D-U-N-S numbers.
Store three D-U-N-S fields: Entity D-U-N-S (this specific company), Domestic Ultimate D-U-N-S (highest parent in this country), and Global Ultimate D-U-N-S (highest parent worldwide).
Build hierarchy from D-U-N-S. Accounts sharing the same Global Ultimate D-U-N-S belong in the same hierarchy. The entity with its own D-U-N-S matching the Global Ultimate is the top-level parent.

When D-U-N-S is worth the investment

D&B data isn't cheap. Verum provides a written, scope-specific charge and schedule after reviewing the records, requested checks, exception rules, and delivery format. It's worth it when:

You sell to enterprise accounts with complex corporate structures
You need to track subsidiaries across countries for territory planning
Your ABM strategy targets corporate families rather than individual entities
You're doing M&A analysis and need to understand who owns what

For SMB-focused sales teams, manual hierarchy management or simpler enrichment tools are usually sufficient.

Why Does Name Normalization Matter for Hierarchies?

Account hierarchies and company name normalization are deeply connected. You can't build clean hierarchies if your account names are a mess.

Consider these real examples:

Account Name in Salesforce	Actual Company	Should Be Child Of
Google LLC	Google	Alphabet Inc.
google	Google	Duplicate, merge with above
Google Cloud	Google Cloud Platform	Google LLC (or Alphabet)
YouTube	YouTube	Google LLC (or Alphabet)

Before you build hierarchies, normalize your account names. Remove suffixes, standardize capitalization, and resolve obvious duplicates. Then you can identify parent-child relationships with much less noise.

The workflow: normalize first, deduplicate second, build hierarchy third. Trying to build a hierarchy on top of messy, duplicated data just creates a messy, duplicated hierarchy.

Handling Subsidiaries and Divisions

Subsidiaries are the most common hierarchy use case, and they come in a few flavors.

Wholly-owned subsidiaries

Clear parent-child. "Instagram" is a child of "Meta Platforms." These are straightforward to model because the ownership is unambiguous.

Joint ventures and partial ownership

Worked example: Company A and Company B share ownership of Company C. A single-parent CRM hierarchy cannot express both relationships, so record the chosen primary parent and preserve the other ownership link in a separate relationship field or review note.

Divisions without separate legal entities

A company has a "Commercial" division and a "Government" division, but they're not separate registered entities. Whether to create child accounts depends on whether you sell to them separately. If the commercial team and the government team have different buyers, different procurement processes, and different agreements, treat them as separate accounts in a hierarchy. If they share a single procurement team, one account is enough.

Recently acquired companies

When Company A acquires Company B, create the parent-child relationship before deciding whether to merge. Keep the acquired account separate while its agreements, contacts, and open opportunities still refer to that entity, and make the later merge decision from documented business rules.

How Do You Report on Account Hierarchies?

Group reports by a custom Ultimate Parent field. That's the short answer, because Salesforce's standard reports don't roll up data across parent-child relationships automatically.

The Ultimate Parent approach

This is the simplest and most common solution. With the Ultimate_Parent_Account__c field populated on each account, you can:

Group any report by Ultimate Parent to see total pipeline across a corporate family
Sum revenue across child accounts
Count total contacts across the hierarchy
Build dashboards that show your top corporate relationships

Roll-up summary fields

Salesforce doesn't support native roll-up summary fields on Account-to-Account (only master-detail, which Account hierarchies are not). You'll need Apex, Flow, or a tool like Rollup Helper to aggregate child account data on the parent.

Common roll-ups:

Total Open Pipeline: Sum of open Opportunity amounts across child accounts
Total Closed Won (Selected Reporting Window): Revenue across the hierarchy
Total Contacts: Count of contacts across child accounts
Number of Child Accounts: Quick indicator of hierarchy complexity

SOQL for hierarchy queries

If you're comfortable with SOQL, you can query parent-child relationships directly:

Find child accounts for a parent:

SELECT Id, Name FROM Account WHERE ParentId = 'PARENT_ACCOUNT_ID'

Find accounts and their parent names (one level):

SELECT Id, Name, Parent.Name FROM Account WHERE ParentId != null

SOQL doesn't support recursive queries, so you can't walk an entire hierarchy in one query. For deep hierarchies, you'll need Apex to traverse levels programmatically.

Common Hierarchy Mistakes

Building hierarchy before cleaning data. If "Acme Corp" and "Acme Corporation" are separate accounts, and you make "Acme Corp" a child of "Acme Industries" but miss "Acme Corporation," you've got a broken hierarchy. Normalize names and merge duplicates first.

Making hierarchy too deep. Five levels of hierarchy means five levels of maintenance. Each time a company restructures, you have to update the chain. Keep it as shallow as your sales motion allows.

Not maintaining the Ultimate Parent field. If you populate Ultimate Parent once and rarely update it, it'll go stale as hierarchies change. Automate it with a Flow or trigger that fires when ParentId changes.

Confusing hierarchy with territory. Account hierarchies represent corporate structure. Territories represent sales coverage. A parent account and its child accounts might be in different territories. Don't use hierarchy to solve a territory assignment problem.

Forgetting about reporting. Building a beautiful hierarchy that nobody can report on is wasted effort. Plan your reporting approach (Ultimate Parent field, roll-ups, custom reports) before you build the hierarchy rather than after.

When to DIY vs. Get Help

If you have fewer than 500 accounts and a straightforward sales motion, you can set up hierarchies manually. Create the custom fields, link accounts through ParentId, and build a simple Flow for Ultimate Parent. A few days of work.

For larger databases, the challenge is identifying which accounts belong together. That requires normalization, deduplication, and often external data (D-U-N-S or similar) to map corporate structures.

We help companies build account hierarchies as part of larger data cleanup engagements. The normalization and deduplication we do as part of our data cleaning services normally surfaces the relationships that hierarchies need. If you're staring at a messy Account list and don't know which companies are related to which, reach out.

Common Questions About Salesforce Account Hierarchies

How many levels can a Salesforce account hierarchy have?

Check the current platform documentation for hierarchy limits in the edition and workflow you use. Keep the operational hierarchy as shallow as the buying model allows, and test reporting and navigation before a bulk import.

What's the difference between Parent Account and Ultimate Parent in Salesforce?

Use the native Parent Account relationship for the immediate link. If reporting needs an ultimate-parent value, define a separate field and a documented process to populate and refresh it. Test the logic on acquisitions, divestitures, and shared brands before applying it broadly.

Should I use D-U-N-S numbers for the CRM account hierarchies?

If you sell to enterprise accounts with multiple divisions and subsidiaries, D-U-N-S numbers are the most reliable way to map corporate structures. They're especially valuable for global companies. For SMB-focused teams, manual hierarchy management or simpler enrichment tools are usually enough.

How do I report on account hierarchies in Salesforce?

Standard reports don't roll up across hierarchies. The simplest approach: create an Ultimate_Parent_Account__c field on each account and group reports by it. For aggregate metrics (total pipeline, total revenue across subsidiaries), use roll-up tools like Rollup Helper or custom Apex to sum child account data on the parent.

Can I build an account hierarchy without D-U-N-S numbers?

Yes. Group accounts by website domain, normalize company names to catch variations, and link the obvious parent-child pairs through ParentId. This works well for databases under a few thousand accounts. You lose the cross-border subsidiary mapping that D&B provides, so global enterprise hierarchies will have gaps you'd need to fill by hand.

What happens to the hierarchy when a company gets acquired?

Set the acquired company's Parent Account to the acquirer and rerun the Ultimate Parent automation. Keep the records separate while agreements, contacts, and open opportunities still refer to the acquired entity, then apply the documented merge rule after review.

Messy accounts with no hierarchy? We can normalize your company names, deduplicate, and build the parent-child relationships so your reporting works.

Get a Free Account Assessment

About the Author

Rome Thorndike founded Verum. He spent the back half of his career running B2B sales at Snapdocs and Datajoy, watching every team waste cycles on contact data that should have been clean to begin with.