How to Use the Account Hierarchies Match Node in LeanData
When enterprise accounts are structured with subsidiaries, matching a lead to the right account is only half the problem. Routing decisions often need to reflect ownership at the parent or ultimate parent level, not the subsidiary. This video shows how to configure the Account Hierarchy Match Node in LeanData FlowBuilder to pull in the right account from your hierarchy and use it to drive routing.
What You Will Learn
- Understand the difference between LeanData account hierarchies and the native Salesforce parent account field
- Configure the Account Hierarchy Match Node using a matched account variable as the input
- Select which hierarchy members to return, including top-level parent, direct parent, direct children, or all descendants
- Store the result as a single account or a collection variable for downstream use
- Route a lead based on the owner of the ultimate parent account, even when the lead matched to a subsidiary
Why This Matters
Enterprise accounts are rarely flat. When ownership is managed at the corporate level, routing to the subsidiary account owner produces the wrong outcome. The Account Hierarchy Match Node closes the gap between where a lead lands and where it actually needs to go, giving RevOps teams precise control over routing logic without adding complexity to the broader graph.
Use Cases
- Routing logic requires filtering hierarchy members before selecting a target account
- A lead matches to Sony USA, but routing should go to the owner of Sony Corporation
- An update at a parent account level needs to trigger actions across multiple child accounts
- Ownership models are managed at the ultimate parent, not the subsidiary
- Teams need to route to the direct parent rather than the top-level parent in a tiered hierarchy
Transcript
When you’re routing a record, it’s common to match to an Account, and then make a decision based on data on that Account.
But if you’re working with enterprise accounts, that “right Account” isn’t always the one you matched.
Example: a Lead matches to “Sony USA”, but routing is determined by the ultimate parent “Sony Corporation”. Or you need to update multiple child accounts when something changes at the parent level.
That’s where the Account Hierarchy Match node comes in. It lets you take one Account as an input, and pull in related Accounts from your LeanData Account Hierarchy, and store either a single Account or a collection of Accounts in a variable for downstream logic.
Lets walk through a common use case: routing a Lead based on the ultimate parent Account owner, even when the Lead matched to a separate subsidiary Account.
Here’s the scenario.
A Lead comes in and matches to a subsidiary Account like “Sony USA”. But your ownership model is managed at the enterprise level, so the owner you want is the owner of the top-level parent Account: Sony Corporation, not the subsidiary, Sony USA
So the goal is:
- Match to an Account as usual.
- Use Account Hierarchy Match to retrieve the top-level parent.
- Route using that parent Account’s owner.
Please note, before you build this, you need to have already built your LeanData Account Hierarchies This node is powered by that hierarchy build.
Now let’s jump into FlowBuilder.
At a high level, we’re going to do three things:
- Match to an Account.
- Pull the hierarchy member we care about.
- Use that result for routing.
In most graphs, you already have an Account from a match step.
For example, you might have a Lead-to-Account match node upstream that outputs a “Matched Account” variable.
That matched Account is what we’ll feed into the Account Hierarchy Match node.
From the node bar, drag in the Account Hierarchy Match node, and include it somewhere after the match path from your original account match node.
Open the node configuration.
First, choose the input variable that contains the Account you want to use as your starting point. In our case, that’s the “Matched Account” variable.
Next, select which hierarchy members you want to return.
For this use case, we want the Top-Level Parent, because we want enterprise-level ownership.
Depending on your use case, you could choose other scopes, like Direct Parent, Direct Children, All Descendants, or Entire Hierarchy.
If your hierarchy includes a lot of members, filters let you narrow down the results.
But For this use case, we’re only looking for the one Top-Level Parent with no filters.
Next choose whether you want to return a single Account or a collection.
There is only one top level parent, so it will be single record and we will store it in a variable like “Ultimate Parent Account”.
If you were doing something like “All Descendants” or “Entire Hierarchy”, you’d would want to return a collection instead.
Then we’ll hit done
Now that we have the Ultimate Parent Account in a variable, we can route based on it.
We’ll pull in a Route to Matched Account node, and select the Ultimate Parent Account variable, and select the owner of that ultimate parent account
And we are done. just a reminder that this follows the account hierarchy that you build within LeanData’s account hierarchies feature, not the native Salesforce parent account field. You want to make sure that is set up appropriately.
The account hierarchy match note is the missing link between matching to an account and also applying hierarchy-aware logic. I hope that helps.
