Salesforce Account Hierarchy: Setup, Parent-Child & Normalization

March 2026 · 12 min read

Your biggest customer is a Fortune 500 with three divisions, each operating under a slightly different name. Your sales team has created separate Account records for each: "Acme Industries," "Acme Healthcare Solutions," and "Acme Digital." Three different owners. Three separate pipelines. Nobody realizes the company just spent $400K across those three accounts combined, which would make them your largest customer by a wide margin.

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 isn't complicated, but 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 actually report on hierarchies once they're built.

How 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

Not every related company should be a child account. The decision depends on your sales motion.

Scenario	Recommendation
You sell to divisions separately (different buyers, different contracts)	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 actually sells at these different levels.

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.

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

Using D-U-N-S Numbers for Hierarchy

D-U-N-S numbers from Dun & Bradstreet are nine-digit identifiers assigned to every 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 actually 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

1. 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.
2. 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).
3. 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. A D-U-N-S enrichment project for 10,000 accounts can cost several thousand dollars depending on your provider. 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, not 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.

Company Name Normalization and 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

Company A owns 50% of Company C, and Company B owns the other 50%. Salesforce hierarchies don't handle shared ownership natively. Pick the primary parent (usually the operating partner) or keep the joint venture as a standalone with notes about the relationship.

Divisions without separate legal entities

A company has a "Commercial" division and a "Government" division, but they're not separate legal 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 contracts, 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, don't rush to merge records. Create the parent-child relationship first. Keep both accounts active for 6-12 months while the integration settles. Contacts and Opportunities on the acquired company's account stay attached to that account. You can always merge later, but splitting a merged account is much harder than maintaining a hierarchy.

Reporting on Hierarchies

Building the hierarchy is only useful if you can report on it. Unfortunately, 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 every account, you can:

• Group any report by Ultimate Parent to see total pipeline across a corporate family
• Sum revenue across all 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 all open Opportunity amounts across child accounts
• Total Closed Won (Last 12 Months): Revenue across the hierarchy
• Total Contacts: Count of contacts across all 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 all child accounts for a parent:

SELECT Id, Name FROM Account WHERE ParentId = '001XXXXXXXXXXXX'

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. Every 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 never 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, not 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. If you've got 10,000+ accounts and no existing hierarchy, it's a meaningful data project.

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 naturally 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

Related: All Salesforce Guides | Company Name Normalization | Duplicate Management | Data Enrichment