# Salesforce Account Hierarchy: When a Parent Account Helps a Small Sales Team and When It Hides Deals

https://salesbond.app/blog/salesforce-account-hierarchy-parent-account-when-to-use/
Published: 2026-10-22 · Updated: 2026-10-22

A Salesforce account hierarchy is built with one standard field, Parent Account, and a small sales team needs it only when the subsidiary has its own buyer and its own budget. If it does not, keep one account, add the people as contacts and the sites as addresses, and skip the hierarchy.

## What Parent Account actually does (and does not)

Parent Account is a standard lookup from one account to another account. In the API it is the `ParentId` field on Account ( [Salesforce Object Reference: Account](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_account.htm)). That is the whole mechanism.

You set it on the subsidiary: edit the account, pick the head office in Parent Account, save. The family then shows up through View Account Hierarchy on the account page. If the button is missing, an admin has it switched off in Account Settings ( [Salesforce Stack Exchange: hiding the View Account Hierarchy icon](https://salesforce.stackexchange.com/questions/423630/how-to-hide-view-account-hierarchy-icon-from-highlights-pannel)).

What the field does not do matters more for a manager. It does not move opportunities: a deal stays on the account where the rep created it. It does not merge contacts. And it does not change ownership; the child keeps its owner, the parent keeps its own.

So the hierarchy is a map, not a container. In this article a child account simply means an account whose Parent Account is set.

## One question: does the subsidiary buy on its own?

Create a child account only when the entity has its own decision maker and its own budget.

A regional distributor with its own managing director who signs its own contracts: yes. Give it an account, set Parent Account to the group, and expect its own opportunities. A branch office of the same customer where the head office signs every order: no. That branch is a contact (the branch manager) and a shipping address on the one account. A second record would only split the history in two.

The test fails most often with multi-location customers. A retail chain with three hundred stores, set up one account per store, is three hundred records and still one buyer. Three hundred places where a deal can be logged and forgotten.

We hold to the question even when it feels pedantic. Your CRM should mirror who buys, not the customer’s org chart.

![Decision tree: create a child account only if the subsidiary has its own buyer and budget.](https://salesbond.app/wp-content/uploads/2026/10/salesforce-account-hierarchy-parent-account-when-to-use-2.png)

## Where deals live: opportunities on child, forecast on parent

Once a child account exists the opportunity goes on the child. The buyer is there, the contact roles are there, and the signed order will name that legal entity. Putting the deal on the parent “so the manager sees it” breaks the record the rep works every day, and the rep will quietly stop updating it.

The parent is where you want the number, not the deal. A group of four subsidiaries is one customer in your forecast, even though it is four records in Salesforce. A parent owner on Salesforce Stack Exchange asked exactly this: how to see everything underneath the parent ( [Report on Account with their Opportunities](https://salesforce.stackexchange.com/questions/229862/report-on-account-with-their-opportunities)). Neither answer was accepted, but both land on a report grouped by Parent Account. Don’t wait for the parent record to show the total.

## The manager view: an account hierarchy report of deals by parent

The first report answers “how much pipeline do we have with this group?” Start an opportunities report and group it by the account’s Parent Account instead of by Account. Each group is then one customer as the business sees it, with its subsidiaries’ deals summed underneath. Filter to open opportunities and save it. One report on Monday replaces opening four account pages.

The second report is the one nobody builds, and it catches hierarchy rot. List accounts where Parent Account is filled in and there are no open opportunities. Then read the the list. Some are real subsidiaries that have not bought yet; leave them. The rest are branches that failed the one-question test on the day they were created, and each will one day get a deal that never shows up in the pipeline review, because nobody opens a branch account.

Run both monthly. If you keep an account plan on the parent, the first report is its pipeline line (see our note on [account plans in Salesforce and what the manager checks](https://salesbond.app/blog/salesforce-account-plans-manager-check/)).

A disclosure: we build SalesBond, a sales management layer on top of the CRM a team already uses, and it works with Salesforce. Its Deal Health score checks open deals against more than 20 rules. It does not decide whether an account should exist; that is still a call for someone who knows the customer. [Check your CRM with SalesBond](https://salesbond.app/).

## How hierarchy creates duplicates (and the check)

Hierarchies breed duplicates in a specific way. Say a rep searches for “Northwind”, sees a child account called “Northwind Logistics GmbH”, decides it is the wrong one and creates “Northwind” again. Now the group report shows two customers where there is one.

The second source is the opposite move. A rep opens the parent, can’t find the deal they remember, and creates the opportunity on the parent even though the child already carries it. Same deal, two records, two close dates, and a forecast that counts it twice.

The check is boring and it works. Once a month, search account names that share a first word, and scan opportunities sitting on parents that also have children; those usually belong on one of thier children. Matching and duplicate rules can flag some of these name collisions, though not every variant of a company name. We wrote up [which duplicate rules a Salesforce manager should actually check](https://salesbond.app/blog/salesforce-duplicate-rules-matching-rules-manager-check/) separately. Set them before you build a hierarchy, not after, since every child record is one more candidate for a near-match.

## How many levels, and who sees the child’s deals

Two levels are enough for a small team: parent and child. The platform won’t stop you; an accepted answer on Salesforce Stack Exchange says there is no effective depth limit, though past five levels it gets impractical because formulas and SOQL traverse at most five levels up ( [Salesforce Stack Exchange: Max level number of accounts in an account hierarchy](https://salesforce.stackexchange.com/questions/407180/max-level-number-of-accounts-in-an-account-hierarchy)). A grandchild account passes the one-question test about as often as a branch office does, which is almost never.

Access is a separate question. Parent Account links the records; it does not by itself give anyone access to the child’s opportunities. Access to records a user doesn’t own comes from organization-wide defaults, the role hierarchy, sharing rules and manual sharing ( [Trailhead: Improve Record Access Control in Your Org](https://trailhead.salesforce.com/content/learn/modules/data_security/data_security_records)). Our guide to [sharing rules for opportunities on a small sales team](https://salesbond.app/blog/salesforce-sharing-rules-opportunities-small-sales-team/) covers that setup. If several people genuinely work one subsidiary’s deals, a team on the opportunity or the account is cleaner than a wider sharing rule; we compared the two in [opportunity teams vs account teams](https://salesbond.app/blog/salesforce-opportunity-teams-vs-account-teams/).

Your next step takes ten minutes: build the second report, the child accounts with no open deals, and go through the list with the reps who own them.