A few weeks into an implementation for a B2B telecom-services client, the sales director pulled up his pipeline report and asked a question that exposed the whole problem: "Why does this enterprise customer show up as eleven separate companies, and why can't I see the total revenue we're doing with them?" His reps had been creating one flat account per legal entity, per branch, per regional office. The customer was a single large bank with a headquarters and thirty-odd branches, but in Salesforce it looked like thirty-odd unrelated logos. There was no way to roll revenue up to the group, no way to spot that the wealth-management arm and the corporate-banking arm were both buying from us, and no way for the key account manager to see across the whole relationship.
That is the failure mode account hierarchy exists to prevent. But I've seen the opposite failure just as often, where a team forces a four-level hierarchy onto every small-business account and reps spend five minutes searching for a parent that doesn't exist. Account hierarchy and account teams are deceptively simple features. The config takes an afternoon. Designing them so they fit how the client actually sells, and so visibility lands on the right people, is the real work.
This is the layer most discovery conversations skip, and it's the one that determines whether your account model is an asset or a tax on every data-entry interaction for the next three years.
Decide whether you even need a hierarchy, and how deep
Every account in Salesforce has a Parent Account field, a self-lookup that builds the tree the moment you populate it. Before you populate anything, I run three questions past the client. Does a typical major customer have multiple legal entities, like a group with several subsidiaries? Does the sales process cross entities, where you sign with the holding company but deliver to a subsidiary? Do the executive reports need to roll up across those entities, like group-level revenue with drill-down? If the answer is yes to two of the three, you need a hierarchy. If it's no across the board, build flat accounts and move on. Forcing a hierarchy on customers that don't have one is the single most common over-engineering mistake I see.
When you do need it, resist depth. A two-level model, group as parent and legal entities as children, covers the bulk of mid-market B2B. For larger enterprises I'll go three levels, and four only when the customer genuinely has the structure to justify it. For that telecom client we landed on three: the bank itself at level one, business units like retail, wealth, and corporate banking at level two, and individual branches or subsidiaries such as the securities and insurance arms at level three. Opportunities attach at level three when the deal is a specific service for one branch, and at level one when it's a master service agreement covering the whole group.
The pitfall here is real and I've cleaned it up more than once. A six-level hierarchy where each level is its own account tier means reps can't remember the structure and file accounts at the wrong level, which quietly corrupts every roll-up downstream. When you feel the urge to go deeper than four levels, stop and ask whether the extra depth is really an attribute, like region or business unit, that belongs in a picklist field rather than another account tier. And never let a client talk you into a fake parent account named something like "Banking Customers" to group an industry. Industry is an attribute; hierarchy is ownership and structure. Keep them separate.
Ownership and visibility are two different problems
A point that trips up teams constantly: the parent-child tree grants no access whatsoever. Having read access to a parent account does not let you see its children. The hierarchy is purely organizational. Visibility comes from somewhere else entirely, and you have to design it on purpose.
In the telecom model, each level had its own owner by design. The level-one account belonged to a senior key account manager who worked the board-level relationship. Level-two business units belonged to the sales managers responsible for them. Level-three branches belonged to junior business developers. That distribution of ownership is good for accountability, but it creates an obvious gap: the key account manager owns the top of the tree and, by default, can see nothing underneath. Solving that gap is exactly what account teams and sharing rules are for, and it's worth being explicit with the client that ownership and visibility are separate decisions rather than one bundled choice.
It also helps to keep the user-side hierarchy distinct in everyone's head. The role hierarchy organizes your own people, so a manager rolls up the accounts and forecast of the reps below them. The account hierarchy organizes the customer. Forecasting, in particular, follows the role hierarchy and the owner, never the account hierarchy. One rep can own accounts at several different levels of a customer tree, and the forecast still rolls up by person. Conflating the two is a classic source of "why is my forecast wrong" tickets.
Account teams versus opportunity teams
An account team is the set of users who get access to an account beyond its owner, each with a role and an access level for the account, its opportunities, and its cases. An opportunity team does the same thing but scoped to a single deal. The decision rule I use is simple. Choose an account team when the same group of people works the account continuously, which is the norm for strategic accounts. Choose an opportunity team when the cast changes from deal to deal, like pulling in a specialist or legal counsel for one large pursuit.
For the telecom client's fifty-odd strategic accounts, each carried a standing account team: the key account manager as owner with full access, a sales manager with read on the account and read/write on opportunities, a solution architect with broad read and write on opportunities to keep technical fields current, a customer success manager who could write cases, and an executive sponsor with read-only access for the times they joined a CEO-level meeting. Defining the access levels by role up front is what keeps this from becoming a one-off scramble on every account. And because the key account manager creates many of these, setting up their default account team means the standard cast gets added automatically on every new account they own, which saves a surprising amount of clicking.
Two gotchas worth flagging. First, an account team role of read/write doesn't help if the member lacks the permission set that lets them act on it; check the permission set alongside the team role or you'll get "I have write access but can't edit" complaints. Second, in a multi-level hierarchy you have to decide how the team relates to the tree. Salesforce doesn't natively inherit an account team down to children. The pattern that has worked best for me is a hybrid: put the key account manager and executive sponsor on a team at level one, backed by a sharing rule so they see across the whole group, while the sales managers and junior BDs get team membership only on the specific lower-level accounts they work. The senior people see everything; the junior people see their patch.
Where the data actually rolls up
The reason that sales director couldn't see group-level revenue isn't a bug, it's a design constraint people forget. Parent Account is a lookup, not a master-detail relationship, so Salesforce won't roll up child values to the parent natively. If you want a "Total Won Revenue YTD" figure on the parent that sums won opportunities across every subsidiary, you have to build it. For mid-size projects I reach for the free Declarative Lookup Rollup Summary package; for small ones a Flow with an update-records action; for genuinely complex conditional roll-ups, Apex. Whatever you pick, decide it during design. Discovering at go-live that the executive's headline number doesn't exist yet is a bad week.
The same deliberateness applies to enabling account-contact relationships, which let a single contact relate to several accounts with a role and an active flag on each link. It's the right tool when you have advisors, former executives, or board members who genuinely influence multiple customers and you need to track those connections. But once you enable it, you cannot cleanly turn it back off, so I won't flip that switch until discovery produces a concrete business case. The pattern that bites people is enabling it speculatively, then deciding it's too complex, and having to migrate contacts back to a one-to-one model by hand.
The thread running through all of this is restraint. Account hierarchy, account teams, multi-account contacts, and revenue splits are each individually reasonable, and stacking all of them on day one produces a model so elaborate that reps quietly stop filling it in and the dashboards built on top go quietly wrong. Start with the shallowest hierarchy that answers the client's real questions, give visibility to exactly the people who need it, and add the next layer only when a concrete requirement demands it. The account model you can actually keep clean beats the elegant one nobody maintains.
Implementing or optimizing Sales Cloud? Our Salesforce team runs discovery, designs the sales process, and configures Sales Cloud on production engagements. Get in touch ->
See our full platform services for the stack we cover.
