---
title: "Account Hierarchy Routing: A RevOps Playbook for Salesforce"
id: "45271"
type: "post"
slug: "account-hierarchy-routing"
published_at: "2026-05-26T22:42:34+00:00"
modified_at: "2026-05-26T22:42:36+00:00"
url: "https://www.leandata.com/blog/account-hierarchy-routing/"
markdown_url: "https://www.leandata.com/blog/account-hierarchy-routing.md"
excerpt: "Get a step-by-step guide for account hierarchy routing in Salesforce. Understand how to route leads, contacts, and account updates based on parent-child relationships between corporate entities."
taxonomy_category:
  - "Account Hierarchies"
  - "Intelligent GTM Orchestration"
  - "Lead Routing"
taxonomy_post_tag:
  - "account based marketing"
  - "account hierarchy routing"
  - "Account-based strategies"
  - "lead routing Salesforce"
  - "RevOps"
  - "Salesforce account hierarchy"
---

May 26 2026

# Account Hierarchy Routing

## A RevOps Playbook for Salesforce

Account Hierarchiesaccount based marketing

##### *Summary*

Account hierarchy routing is the practice of routing leads, contacts, and account updates based on parent-child relationships between corporate entities in Salesforce. Most RevOps teams know they need it. Here’s a step-by-step guide for building it.

### What You’ll Learn

- Why native Salesforce hierarchy data is not enough for routing decisions
- What data and tools you need before building hierarchy-aware routing logic
- How to route to an ultimate parent account owner or nearest regional account owner
- How to cascade ownership changes across an entire account family

## The Routing Rule Most Ops Teams Get Wrong

Most [routing logic](https://www.leandata.com/blog/10-lead-routing-plays-you-didnt-know-you-could-do-in-leandata/)
 rests on a single assumption: The account you match to is the account you route to.

That assumption works for simple sales motions. It breaks the moment you sell into enterprise companies.

A lead from Waymo should probably go to the rep who owns Alphabet. A lead from a Sony subsidiary in Chicago might belong to a regional owner, not the global account manager. When your team reassigns a parent account, dozens of child accounts need to update too.

This is [account hierarchy](https://www.leandata.com/blog/account-hierarchies-for-b2b-teams/)
 routing. **No practical guide for it exists anywhere**. Most routing documentation stops at [matching](https://www.leandata.com/blog/salesforce-lead-to-account-matching-the-easy-way/)
 a lead to an account.

This playbook picks up from there.

## Why Salesforce’s Native Hierarchy Data Falls Short

Salesforce includes a Parent Account field on every account record. It is a lookup to one other account, one level up. That’s the full extent of it.

If you want to know whether an account has children, Salesforce cannot tell you from a standard field. If you want to know the ultimate parent three levels above, you need custom configuration or a separate query.

For routing logic, this gap shows up in a few ways:

1. You can’t write a standard routing rule that says “route this lead to the owner of the ultimate parent account.” Salesforce does not surface the ultimate parent as a native, queryable field for that decision.
2. You cannot traverse the hierarchy to find the nearest regional entity. And, when ownership changes at the parent level, nothing automatically propagates to child accounts.

The native setup is enough for a list view. It is not enough for routing decisions.

For a deeper look at where Salesforce parent-child account tools fall short, see [Parent-Child Accounts in Salesforce: What Works, What Doesn’t, and What to Do About It](https://www.leandata.com/blog/parent-account-salesforce-hierarchy-limitations/)
.

## What You Need Before Building Hierarchy-Aware Routing

Hierarchy-aware routing requires three things in place before you touch a single routing rule.

### #1 Clean, Consistent Hierarchy Data in Your CRM

Your accounts need reliable parent-child relationship data. The source can be an enrichment provider like ZoomInfo or D&B, your own maintained Parent Account field, or a combination. The key is consistency. If a significant portion of your accounts have no parent data, your routing logic will fail on those accounts.

### #2 A Structured Hierarchy Build

Routing tools that support hierarchy logic need a complete, traversable hierarchy object, not just a Parent Account lookup. [LeanData Account Hierarchies](https://www.leandata.com/resources/account-hierarchies/)
 builds this by mapping two fields: a unique company identifier (like a ZoomInfo Company ID or D&B DUNS number) and a parent company identifier.

From those two fields, it constructs the full multi-level hierarchy and stores it in a custom object that routing logic can reference in real time.

The setup is straightforward:

1. Navigate to Routing, Account Hierarchies, Configuration inside LeanData
2. Name the hierarchy build
3. Select the object where your enrichment data lives
4. Map the unique ID and parent ID fields, and click Build.

The build can take up to an hour for large orgs, however, the LeanData platform maintains it automatically after that. When a new account is created or enrichment data changes, the hierarchy updates without a manual rebuild.

### #3 Routing Logic That References Hierarchy Members

This is the actual gap most teams hit. Even with clean hierarchy data, your routing tool needs to traverse that hierarchy and retrieve specific members: the ultimate parent, the direct parent, direct children, all descendants, or the entire family.

Without that capability, you route to the matched account and ignore the hierarchy entirely.

LeanData’s Account Hierarchy Match Node in FlowBuilder handles this. It takes a matched account as input, lets you select which hierarchy members to retrieve, applies optional filters, and stores the result as a variable for downstream routing actions.

It works regardless of whether the native Salesforce Parent Account field is populated.

## Three Routing Scenarios, Step by Step

### Scenario 1: Route to the Ultimate Parent Account Owner

**The situation**

A lead comes in from Waymo. Your account matching logic correctly identifies Waymo in Salesforce. But your ownership model operates at the enterprise level. The rep who owns Alphabet is responsible for all Alphabet entities, including Google, YouTube, Waymo, and DeepMind.

Routing this lead to whoever owns the Waymo account means the wrong person gets it.

**What data you need**

- A hierarchy linking Waymo to Google to Alphabet in a traversable structure
- A defined “ultimate parent” relationship in that hierarchy
- Clear ownership at the Alphabet account record

**What the routing decision tree looks like**

1. Lead enters the routing flow
2. Lead-to-Account matching identifies Waymo as the matched account
3. Routing logic runs a hierarchy lookup: given this matched account, retrieve the top-level parent account
4. Alphabet is returned and stored as a variable
5. The lead routes to the account owner of Alphabet

All of these steps are easily built in LeanData’s no-code, drag-and-drop FlowBuilder.

### Scenario 2: Route to the Regional Account Owner

**The situation**

A lead comes in with the company name Sony. Your matching logic hits Sony Corporation, the global parent. But your ownership model is territory-based. The lead’s billing state is Illinois. You have Sony North America in your hierarchy. The right owner is the rep covering that regional entity.

This is the opposite of Scenario 1. The hierarchy is too broad by default. You need to route down or laterally, not up.

**What data you need**

- A hierarchy that includes regional and subsidiary entities, not just the global parent
- Geographic or territory attributes on accounts (state, country, region)
- Routing logic that can traverse the hierarchy and filter results

**What the routing decision tree looks like**

1. Lead enters the routing flow
2. Lead-to-Account matching returns Sony Corporation as the matched account
3. Routing logic runs a hierarchy lookup: given this matched account, retrieve all descendants
4. Filter those descendants by geography: which entity covers the lead’s state or region?
5. Sony North America is returned as the matching regional account
6. The lead routes to the owner of that regional account

### Scenario 3: Cascade Ownership When a Parent Account Owner Changes

**The situation**

Your enterprise account team just went through a territory realignment. The rep who owned Google is moving to a new segment. The new rep taking over Google should also own every entity in the Google family.

That includes YouTube, Waymo, DeepMind, and a dozen other connected accounts. Manually updating each one is a full day of work, and if anyone misses one, two reps now both think they own the same account.

This is an account update scenario, not an inbound lead scenario, but it runs on the same hierarchy logic.

**What data you need**

- An active hierarchy mapping all child and grandchild accounts under Google
- An account routing graph triggered by changes to the Owner field on a parent account record
- A hierarchy lookup that retrieves all descendants of the changed account

**What the routing decision tree looks like**

1. A trigger fires when the Owner field changes on the Google account record
2. The routing flow takes Google as the input
3. A hierarchy lookup retrieves all descendants: direct children, grandchildren, and beyond
4. For each account in that collection, the Owner field updates to match the new parent owner
5. Optionally, a notification fires to alert the new owner of their full account family

Show video transcript    Isabel Zou 00:00  
 And I’m really excited to talk about our new account hierarchies feature set. So maybe just to take a step back before I jump into what we built here today in Salesforce, your hierarchy data is is pretty limited, as you know, you do have that parent account field, so you’re kind of limited to just knowing who the parent of a certain account is, as any one time, maybe the ultimate parent, you know, if that was actually populated, but you don’t really know the entire structure of the hierarchy, such as, how many children are actually? How many children does this account have? Or when you talk about the whole hierarchy, how deep is it really? How many levels are there? So to that end, just with Salesforce itself, it’s pretty limiting how you can actually operationalize on this hierarchy data. To that end, our account hierarchies feature is really to help you actually access that information. So what we do is we help you map, build and maintain your account hierarchies based off of data that you might already have in your CRM, for example. Maybe it’s something like zoom info data that you already have, or DUNS and Bradstreet, or maybe just your own custom data. What we do is we take that help put that into a specific hierarchy object, so that you can actually now start to see those hierarchy structures in its entirety, and as well as operationalize on those account relationships through our orchestration and routing automation. Yeah, if you go to next slide, I can start introducing more specific features on your list, sure, and yeah, it really starts out with the mapping functionality. So what we do here is we are building and storing those hierarchy relationships in a lean data hierarchies custom object. This object stores all of that information in the hierarchy, basically like every account that actually exists as a part of that hierarchy, to really help you understand those relationships. Now, as a part of this, we are also continuously maintaining your hierarchies as accounts are added or updated. So maybe a new account comes in, or some kind of hierarchy data was updated on an existing account. We are listening for that, and we will update those accounts and put them in the right hierarchies appropriately. So that’s no longer something you might have to manually do. We will pick that information. Now another piece of this is we can also help you update your native parent account field on your account records. So take that Zoom info example, Zoom info example, you might have that company ID information just in a separate field. We can take that and actually use that to link your actual parent accounts in that parent account, standard Salesforce field. Now, as a part of account hierarchies management in general, there’s obviously the possibility to have some like more messy hierarchy data in your system. What we do is we help surface those errors kind of show when a hierarchy might be broken, as well as flagging duplicate accounts that might exist in a hierarchy to help resolve those so we’ll surface those for new admins, and you can kind of open those up and resume them accordingly. Now, yeah, like I mentioned here, once again, we are just helping you leverage that full hierarchy context with this mapping feature, you’d be able to use it in a visualization, which I’ll talk to later, as well as use it in your routing to really help with those more complex hierarchy aware routing use cases  
  
 Kevin Au 03:37  
 before we move On. So just to ensure that I’m understanding this properly, so we’re using informations from some enrichment providers and third party to be able to follow the hierarchy relationships there. We’re not using the we’re not following the parent account field that’s natively in Salesforce, but we can update that if, if we need to correct.  
  
 Isabel Zou 04:01  
 Yeah, correct. So yes, we will be using that data that you might have already enriched in your CRM. Now as a note, we’ve seen some companies where they do actually just update that parent. Feel we can also build those hierarchies off of that standard field. Once again, it’s different in that we are actually building out the entire hierarchy, not just looking at what parent like that single parent value,  
  
 Kevin Au 04:27  
 okay, got it. You might talk about this later, but in terms of utilizing these hierarchy relationships within your orchestration, your routing, that’s something that we can do as well, right?  
  
 Isabel Zou 04:39  
 Yeah, so it’s actually a good transition to my next slide. There we are introducing a new account hierarchy match node so that you can actually reference those hierarchy members from a given account, so that you can use that in your Flow Builder flows, for example, you might want to use it in routing or maybe updating certain records or. Notifying about that. So to break down how this works, you can choose, you essentially provide which account that we’re looking at. So maybe you know in your lead flow, you found a matched account, and you want to see, Hey, is that account actually part of a broader, broader hierarchy? You could add that account, and what we do is we actually retrieve the hierarchy for that account and allow you to select what members of that hierarchy that you actually want to use as information in your graph. So some examples here are, you can actually reference figure out who that top level parent is, maybe just pull in all the descendants of a certain account in the hierarchy so that you can use it in your routing flows. We often hear customers use this where they might want to choose to route prospects and opportunities from a subsidiary account directly to the top level parents. That’s one use case we’ve heard. But we’ve also heard companies have more kind of divisional structures, divisional territory structures. So to that end, with an account, you can actually identify which are those divisional subsidiaries and the owners that should actually own them as well.  
  
 Kevin Au 06:09  
 I see just taking a look at the screenshot. I’m not sure if it’s readable for a lot of folks, but it looks like you can select more than one member of the hierarchy here. So what’s a use case that where you would need to identify more than like, the parent account or the child account?  
  
 Isabel Zou 06:27  
 Yeah, so what we’ve seen this is more for kind of proactive notifications for owners. So you know, an account comes in and the person who’s working that account, they might actually want to see, like, hey, what else? What? Just what? Give me some more context on this account. So, like, the entire hierarchy case is a good example that you would store that set of accounts in a variable, and you might use that in a notification down the line, being like, hey, like you’re working this account, but it’s actually part of this hierarchy with these members. If you check for any opportunities that already open under any of those numbers.  
  
 Kevin Au 07:01  
 Okay, no, that’s that’s helpful. Great. Anything else on this slide?  
  
 Isabel Zou 07:07  
 Um, no, let’s get to the next one here. All right, so this is the other piece of our account hierarchies, functionality. Um, really, the end user here are those that work in Salesforce, but we do include a visualization that is configurable as well as Salesforce permissions aware. So this is a visual force page that you can put in Salesforce, and it will display all of the parent child relationships across the entire account hierarchy. So this is moving beyond just knowing what the parent is, what the ultimate parent is you actually see that account. You see the rest of the accounts in that hierarchy, and you see where in the hierarchy that account sits. Now this is going to be configurable. You can add whatever fields that might be relevant to your to your users, and additionally, you can add some related object tabs for any standard or custom object, so that you can actually get complete visibility into those related records across the hierarchy. Example here is opportunities. Something that’s really helpful is being able to see every open opportunity that exists in an entire hierarchy. So that you aren’t necessarily you can kind of see where you are already maybe conversing with a certain, certain prospect within that hierarchy itself, that can help with finding opportunities for more unified selling, as well as like, maybe cross selling across the actual hierarchy. Part of this, we’ve also introduced roll up filter footers so that you can calculate those metrics across the hierarchies, something may be like, Hey, how many unique owners do I have across this hierarchy? Maybe, if it’s a high number, something might be wrong there. There’s opportunity to come in and kind of fix that, and then just CSV export support so that you can actually report and use some more deeper analysis on this.  
  
 Kevin Au 08:56  
 Wow, there’s a lot of stuff here. It looks like it supports custom relationships as well, not just opportunities and contacts, things you would expect to be a part of an account relationship, but we even see things like lean data journeys, service contracts and things like that. So that’s  
  
 Isabel Zou 09:15  
 fully customizable, yes? So yeah, that’s fully customizable. In the configuration page, you can choose which objects to actually show, really job to show, so long as it is related to the account that’s all for your game, so that you’ll see them this under their appropriate accounts. Right?  
  
 Kevin Au 09:32  
 You might have already addressed this, but what is one thing that you might expect folks will start doing differently once they have hierarchy set up and in place?  
  
 Isabel Zou 09:43  
 Yeah, I think really, this is part of just providing more context here. No longer will you just be selling in necessarily isolation on just a certain account level, you can actually see what’s going on across the whole hierarchy, which really represents the corporate structure, right? So you can find any opportunities to maybe sell into other places within that corporate. Just think, well, some of those large enterprise accounts with many subsidiaries, you can actually get that full picture there.  
  
 Kevin Au 10:11  
 Great, awesome. Okay, now question about, what about the accounts that are not yet in your Salesforce system? What do you do about those?  
  
 Isabel Zou 10:22  
 Right? So as a part of that, we do address that with our whitespace discovery functionality. So this is something that you can use to surface any you know, whitespace entities that are actually are part of your hierarchies, but they aren’t necessarily represented in your CRM as an account. Now we’re doing this with an integration with Zoom info. We will leverage the Zoom info information to figure out, you know, which missing, missing companies are in your hierarchies, and surface that within either the visualization or an admin specific page where they can actually see that full list of all of those white space accounts within their CRM. Now the action there would be to create an account, if you kind of decide, like, hey, like, I think we actually do want to create this account so that we can start selling into them. What we do there is, when you do click create account, we do automatically update that with the parents and the parent. Parent enriched information so that it will just be automatically inserted into your hierarchy. Optionally, you can also enrich it with additional firmographic data, if just provided by zoom info. Now, yeah, I think really here is just supporting more strategic account planning, helping with identifying those gaps. I see this happening maybe more on like those quarterly refreshes, where you’re just looking at all of your accounts and seeing like, Hey, where are the missing opportunities that you might want to go tackle?  
  
 Kevin Au 11:52  
 No, that’s really helpful, and it’s really cool that you can create it directly from the interface there. I’m assuming that there’s, there’s plans to expand to other enrichment providers as well, right?  
  
 Isabel Zou 12:05  
 Yeah, that is in the plan. We are talking to additional providers, and we’ll kind of update as we get more more providers.  
  
 Kevin Au 12:13  
 All right. Excellent. Thanks for walking through all of those account hierarchies, features. Anything else that we we missed or failed to mention here?  
  
 Isabel Zou 12:21  
 Um, no, I think, you know, I went through a lot of different features, but it’s really just this entire feature set multiple ways you may actually want to leverage them. Maybe the visualization is useful for specific use cases, while actually automating routing is different. So there’s just a lot of ways you can use this. And yeah, looking, looking forward to kind of seeing how our customers are using this functionality. Yeah.

## Multi-Hierarchy Routing: When One Structure Is Not Enough

All three scenarios above assume a single hierarchy structure. Most organizations start there. But as routing logic matures, one hierarchy starts to create conflicts.

- Your legal and compliance team needs a formal hierarchy based on corporate ownership from D&B.
- Your territory team structures accounts by geography. Your marketing team builds account groupings around buying center relationships.

These are legitimately different views of how accounts relate to each other. Forcing everyone to share one hierarchy means someone is always working with the wrong structure.

LeanData offers multi-hierarchy support. Organizations can configure up to 10 separate hierarchies per org. A routing graph can specify which hierarchy to evaluate. So, a single FlowBuilder graph can route an inbound lead against the sales GTM hierarchy while a separate account update flow references the legal hierarchy.

**Example use cases for multiple hierarchies**

- Maintain a D&B legal hierarchy for compliance and contracts, plus a separate sales-defined hierarchy for routing and [territory planning](https://www.leandata.com/resources/revenue-driven-sales-territory-planning-management/)
- Build parallel hierarchies from D&B, ZoomInfo, and Clay, then use the Account Hierarchy Match Node to evaluate them side by side and identify gaps
- Switch to a region-based hierarchy for territory planning without disrupting the global parent view used for expansion tracking

For RevOps teams managing complex routing across multiple ownership models or territory structures, this removes a real operational constraint.

## Treat Hierarchy Quality as a Routing Dependency

A routing rule is only as accurate as the data it runs against. For flat routing logic (territory, [round-robin](https://www.leandata.com/blog/round-robin-lead-distribution-best-practices/)
, account owner), data quality issues surface fast. A lead goes to the wrong rep, the rep flags it, someone investigates.

Hierarchy routing failures are quieter. If a lead routes to the owner of a stale parent account instead of the correct regional owner, the rep might not know it is wrong. They work the lead. The coverage gap, the missed opportunity, the rep conflict show up later and are harder to trace.

Treat hierarchy quality as an operational dependency, the same way you treat data enrichment or CRM hygiene.

**Three things to act on now**

1. Monitor broken hierarchies. LeanData surfaces an issues table in the hierarchy build that flags circular references, missing self-values, and failed updates. Review it regularly.
2. Rebuild hierarchies when enrichment data changes, not on a schedule. A trigger-based rebuild catches changes in real time. A weekly rebuild leaves a window where routing runs on stale data.
3. Audit coverage at every level. The top of the hierarchy is usually clean. Regional and subsidiary levels are where gaps build up.

## Build the Routing Logic Your Enterprise Accounts Deserve

Routing to the right person at the right level of a corporate hierarchy is one of the highest-leverage things an Ops team can do. It keeps enterprise accounts from getting split between reps, ensures global account managers own what they should, and keeps your [CRM clean](https://www.leandata.com/blog/salesforce-data-quality/)
 when territory changes happen.

Salesforce’s native parent-child structure is a starting point. LeanData Account Hierarchies picks up where it leaves off, giving Ops teams the real-time hierarchy data they need to build routing logic that actually matches how enterprise accounts are structured.

## FAQ

### Can Salesforce handle account hierarchy routing natively?

Salesforce includes a Parent Account lookup field, but it only shows one level at a time. You cannot natively query the ultimate parent, traverse multiple levels, or build routing rules that reference hierarchy members. Doing this without a third-party tool requires custom Apex code and ongoing manual maintenance.

### What is the difference between account hierarchy routing and standard lead routing?

Standard lead routing assigns a lead based on attributes like territory, industry, or company size. Account hierarchy routing goes a step further. It first matches the lead to an account, then traverses the corporate structure to find the right owner based on where that account sits in the hierarchy, whether that is the ultimate parent, a regional entity, or another related account.

### Does account hierarchy routing work if we already use ZoomInfo or D&B for enrichment?

Yes. LeanData Account Hierarchies builds off whatever enrichment data already lives in your CRM. You map the unique company ID field and the parent company ID field, and LeanData constructs the full hierarchy from there. You do not need a separate ZoomInfo integration specifically for account hierarchies.

### What happens to routing when a hierarchy goes out of date?

Routing decisions based on a stale hierarchy will silently fail or produce incorrect assignments. A lead that should route to a regional owner may route to a global parent owner instead, or land in an unassigned queue. LeanData surfaces hierarchy errors in a built-in issues table and rebuilds the hierarchy automatically when account data changes, so routing logic always runs on current structure.