Salesforce models corporate families with the standard Parent Account field. Each subsidiary, franchise or location points to its parent, and the hierarchy view draws the tree. That gives you structure, not totals. Native roll-up summary fields do not cross the parent-child account link. Family-level revenue and pipeline need Flow, Apex or reports grouped by an ultimate parent field. Decide early what one account record represents, then build ownership, sharing and reporting around that answer.
What does the native account hierarchy give you out of the box?
A self-referencing Parent Account lookup on every business account, plus a View Account Hierarchy action that shows the tree. Everything else, including totals, ownership rules and data feeds, is yours to design.
Salesforce Help lists several limits worth knowing before you promise anything to leadership. Check the current documentation, because these details change between releases.
- The Lightning hierarchy page shows up to 2,000 accounts, sorted by name; Classic shows up to 500 child accounts.
- Users only see accounts they already have permission to view, so the tree can look different for each person.
- Admins can choose up to 15 hierarchy columns, such as annual revenue, owner or billing city.
- Salesforce Help says the hierarchy view is not available in the mobile app.
- Person accounts cannot use the Parent Account field at all.
The Account Site field is the native way to tell two locations of the same company apart. Use it, or a consistent naming convention, before the tree grows past a few dozen records.
Should a location be a child account, a record type or its own object?
Make it a child account when you sell to it, own it or report on it separately. Use a custom location object when it is only an address where you deliver or service.
Parent-child accounts suit franchises, subsidiaries and divisions that sign their own contracts or have their own buyers. Record types sit alongside that choice: they separate headquarters, subsidiary and site layouts without changing the structure.
A custom location object keeps the account list short when one customer has hundreds of sites. You lose native hierarchy display for those sites, but opportunities stay on the buying entity. Person Accounts belong to consumer selling and cannot join a corporate tree.
| Modeling option | Use when | Reporting impact | Pitfall |
|---|---|---|---|
| Parent-child accounts | Subsidiaries, franchisees or divisions buy, sign or get served separately | Group by parent or ultimate parent; totals need Flow, Apex or report logic | Deep, inconsistent trees nobody maintains after acquisitions |
| Record types on Account | Headquarters, subsidiary and site records need different fields or processes | Filter or group by record type in any account report | Using record types as a substitute for actual parent links |
| Custom location object | Sites are delivery or service addresses, not buyers | Site counts and activity roll to the owning account through a lookup or master-detail | Reps creating accounts for sites anyway because the object is hidden |
| Person Accounts | You sell to individual consumers, not companies | Consumer reporting works; corporate roll-ups do not apply | Expecting person accounts to sit under a corporate parent |
| Single global account | The customer buys centrally and local units never transact | Simple totals, but no view of regional buying | Hundreds of contacts and deals crammed onto one record |
How do you roll revenue and pipeline up to the ultimate parent?
Stamp every account with an ultimate parent, then total by that field. Native roll-up summaries will not climb the account tree for you.
Roll-up summary fields need a master-detail relationship, and Parent Account is a lookup. Account can still summarize its own opportunities, so each record carries its direct pipeline and closed revenue. The gap is the family total across levels.
- Ultimate Parent lookup: a custom field that Flow or Apex sets to the top account, and resets whenever a parent link changes.
- Formula shortcut: a formula can walk Parent.Parent a fixed number of levels; it breaks when trees grow deeper than you planned.
- Family totals: a scheduled or record-triggered Flow, or Apex, sums child values onto the top account. Test it against large families first.
- Report-time totals: group opportunity reports by the Ultimate Parent field and skip stored totals entirely.
Whichever method you choose, decide how to treat currency and closed-lost deals in family totals. Document the rule beside the field so report builders apply it the same way.
Activity follows a similar pattern. Tasks and events roll up to the related account, not to its parents, so family activity views also depend on the ultimate parent field.
Who owns accounts across a corporate family?
Usually a global account owner at the top and local owners further down. Salesforce stores one owner per record, so the pattern has to be built deliberately.
A common design keeps the global owner on the ultimate parent and puts them on each child's account team with a defined role. Local reps own the child records they actually work. Account teams do not cascade down the tree natively, so Flow or a periodic job usually keeps them aligned.
Territories add another layer. Sales Territories assignment rules look at each account's own fields, so children land wherever their own address or industry sends them. If whole families must stay together, rules can key on an ultimate parent attribute. Our territory management guide covers the model choices in more depth.
Does the account hierarchy change who can see what?
No. Owning or seeing a parent account grants no access to its children, and the role hierarchy is a separate concept.
This surprises global account managers in private sharing models. They open the hierarchy view and see only the branches they already have access to. Grant family-wide access through account teams, criteria-based sharing rules on the ultimate parent field, or territories. The sharing model guide explains how those layers combine.
Where should hierarchy data come from?
From one agreed source, refreshed on a schedule. Manual parent links typed in by reps drift within a quarter.
Many teams license a third-party firmographic data provider that supplies corporate linkage and company identifiers. Salesforce's own Data.com products have been retired, so plan on an AgentExchange (formerly AppExchange) or integration-based source instead. Ask your Salesforce account team which data partners they currently support.
If an ERP already holds legal entities, consider mastering the hierarchy there and syncing parent links into Salesforce. Either way, store the external identifier on each account so matches survive renames.
How do you keep hierarchies clean through mergers and acquisitions?
Treat every acquisition announcement as a data change request. Re-parent the acquired company, merge true duplicates and recalculate ultimate parent values in one controlled pass.
- Find duplicates before re-parenting, or totals will count the same customer twice.
- When merging accounts, check for contacts indirectly related to both records; Salesforce asks you to remove those duplicate relationships first.
- Log who changed a parent link and why, with field history tracking on Parent Account.
- Review orphaned children and single-child parents each quarter.
Our duplicate data cleanup guide covers matching and merge rules. When you acquire a company that runs its own Salesforce org, the org merge guide is the better starting point.
Can one contact work across several entities?
Yes, with Contacts to Multiple Accounts. A contact keeps one primary account and gains indirect relationships to others.
This suits a regional procurement lead who buys for several subsidiaries. There are trade-offs. Indirect contacts do not appear in reports built on the standard Accounts and Contacts report type. Disabling the feature later deletes every indirect relationship.
Which reports show the whole family?
Standard reports grouped by the ultimate parent field answer most questions. Joined reports and analytics tools cover the rest.
- Opportunity reports grouped by ultimate parent, then by child account, show pipeline per family and per branch.
- Joined reports put open pipeline, closed revenue and open cases for one family side by side.
- The hierarchy view's custom columns give reps a quick read without leaving the account.
- CRM Analytics or Tableau can handle recursive hierarchies, but confirm licensing with your Salesforce account team first.
What about bill-to and ship-to accounts from the ERP?
Keep ERP bill-to and ship-to codes from multiplying your account list. Map them to the account that buys, and hold the extra addresses as related records.
B2B Commerce and some ERP integrations expect specific account and address structures. Check those requirements before you design the tree. The wholesale distributor guide walks through this for distribution businesses.
What should a first hierarchy project include?
A written definition of an account, a clean top level and an ultimate parent field. Fancy roll-ups can wait until the foundation holds.
- Define what an account record represents: legal entity, buying unit or site.
- Load or clean parent links for your largest customers first.
- Add an Ultimate Parent lookup, populated and maintained by Flow.
- Configure hierarchy columns and two or three family-level reports.
- Set global and local ownership rules, and decide how teams get access.
- Schedule a quarterly review of parent links, duplicates and orphans.
A multi-region technology-services firm we supported shows the payoff. Its Sales Cloud setup included a multi-entity hierarchy that rolled revenue from individual locations up to parent companies. Executive dashboards and multiple price books sat on top of that foundation.
