Account Hierarchies and Business Account Models

Why This Topic Matters

Accounts are the backbone of the Salesforce data model. Nearly every other core object (Contacts, Opportunities, Cases, Contracts, Orders) hangs off the Account. In the real world, companies rarely exist as a single flat record: a global enterprise has regional subsidiaries, divisions, franchises, and branch offices. Salesforce models this through the Account Hierarchy, and how you design that hierarchy directly affects reporting, data quality, sharing, and the user experience.

For the Advanced Administrator exam, this topic sits inside the Advanced Security and Access domain because the exam writers love to test one subtle but critical idea: the Account Hierarchy does NOT automatically control record access. Many candidates confuse the Account Hierarchy (a data relationship) with the Role Hierarchy (a sharing mechanism). Understanding exactly what the hierarchy does, what it does not do, and how implicit sharing, Owner-based sharing, and the Business vs. Person Account models interact is essential to passing scenario-based questions in this area.

What Is an Account Hierarchy?

An Account Hierarchy is a parent-child structure built using the standard Parent Account lookup field on the Account object. When Account B lists Account A as its Parent Account, B becomes a child of A. Children can themselves have children, producing a multi-level tree: for example, Acme Global (ultimate parent) > Acme Europe > Acme France > Acme Paris Office.

Key facts about the hierarchy itself:
• It is built entirely from the Parent Account field; there is no separate hierarchy object to configure.
• The top-most account with no parent is often called the Ultimate Parent (there is no standard field for this; it is a reporting concept, though you can add a custom field or formula to track it).
• Users can click View Account Hierarchy (Lightning) or View Hierarchy (Classic) from the account record to see the tree.
• In Lightning Experience, the hierarchy view can display up to 2,000 accounts; Classic was limited to 500.
• In Lightning you can customize which fields appear in the tree through Object Manager > Account > Hierarchy Columns (up to 15 columns, with Account Name always included).
• The hierarchy is a lookup, not a master-detail. Deleting a parent does not cascade-delete children; the children simply lose their Parent Account value.
• Roll-up summary fields are not available across the hierarchy because the relationship is a lookup, not master-detail. Hierarchy roll-ups (e.g., total revenue across all subsidiaries) require reports, formula workarounds, flows, Apex, or AppExchange solutions.

Business Accounts vs. Person Accounts

Salesforce offers two account models, and the exam expects you to know the differences and consequences of each.

Business Accounts (B2B model)
• The default. An Account represents a company or organization.
• Contacts are separate records that represent individual people who work at the account.
• Contact Sharing (OWD) can be set independently (Private, Public Read Only, Public Read/Write, or Controlled by Parent).
• The Account Hierarchy, Account Teams, and Contacts to Multiple Accounts all apply.

Person Accounts (B2C model)
• An Account and a Contact are merged into a single record that represents an individual consumer.
• Must be enabled by Salesforce Support (or via Setup in newer orgs) and, once enabled, cannot be disabled.
• Prerequisites: the Account object must have at least one record type, and the Contact OWD must be Controlled by Parent (or Account and Contact OWDs must be identical). After enabling, the Contact OWD is locked to Controlled by Parent.
• Person Accounts use a dedicated record type (the IsPersonAccount flag is set to true). Person Accounts cannot have a Parent Account in the traditional B2B sense and are not typically used in multi-level hierarchies, nor can they be the Account for other Contacts.
• Person Accounts can be added as Contact Roles, used in Campaigns, and related to Cases and Opportunities just like Contacts.
• Person Accounts count against both Account and Contact storage.
• Related Lists such as Contacts and the Contacts to Multiple Accounts feature work differently or are unavailable for Person Accounts.

Many orgs run a hybrid model, using Business Accounts for companies and Person Accounts for individual consumers, differentiated by record type and page layout.

Contacts to Multiple Accounts

Enabled in Setup under Account Settings, this feature lets a Contact be related to more than one Business Account via the Account Contact Relationship object. One account remains the primary (the direct Account lookup); the others are indirect relationships with their own role, start date, and end date. This is often paired with hierarchies, for example when a consultant works across several subsidiaries. Access to indirect relationships is governed by access to both the Contact and the related Account.

How Account Hierarchies Relate to Security and Access

This is the heart of the exam domain. Memorize these principles:

1. The Account Hierarchy is not a sharing model.
Having access to a parent account does not grant access to child accounts, and vice versa. Sharing is determined by Organization-Wide Defaults, the Role Hierarchy, Sharing Rules, Manual Sharing, Teams, Territories, and Apex-managed sharing. If a question asks how users who work the parent account can see all subsidiary accounts, the answer is never simply because of the account hierarchy.

2. Role Hierarchy vs. Account Hierarchy.
The Role Hierarchy grants users access to records owned by users below them in the hierarchy (when Grant Access Using Hierarchies is enabled, which is always on for standard objects). The Account Hierarchy is just a lookup relationship between account records. The exam frequently uses one as a distractor for the other.

3. Implicit Sharing (built-in, cannot be disabled).
• Parent implicit sharing: If a user has access to an Account, they automatically get Read access to that account's child Contacts, Opportunities, and Cases (if they have at least read on those objects), even if OWD for those objects is Private. Account Team members and sharing rules can grant more.
• Child implicit sharing: If a user has access to a Contact, Opportunity, or Case, they automatically get Read-Only access to the parent Account. Opportunity and Case owners also receive the ability to see the Account.
Note that implicit sharing operates on the Account-to-Contact/Opportunity/Case relationship, not on the Account-to-Parent-Account relationship. Owning a child account does not give access to the parent account.

4. Organization-Wide Defaults for Accounts.
Account OWD can be Private, Public Read Only, or Public Read/Write (and Controlled by Parent is not an option for Accounts). Setting Account OWD to Private means users see only accounts they own, accounts shared with them, accounts owned by subordinates in the role hierarchy, and accounts reached through implicit sharing.

5. Tools to grant access across a hierarchy.
• Account Teams: Add specific users with defined Account, Opportunity, Case, and Contact access levels. Default Account Teams can be defined per user. Teams must be set per account; they do not inherit down the hierarchy automatically (though automation via Flow can replicate them).
• Criteria-based Sharing Rules: Share accounts where, for example, Parent Account Name or a custom Ultimate Parent field equals a certain value, to a public group or role.
• Owner-based Sharing Rules: Share accounts owned by one role or group with another.
• Manual Sharing: Account owners (and users above them in the role hierarchy, plus admins) can share individual accounts.
• Enterprise Territory Management: Assign accounts to territories by rules; users assigned to territories gain access to those accounts and optionally their related records. Territory models support their own hierarchy independent of roles.
• Apex Managed Sharing / Flow: For complex logic such as share every account in the tree with the owner of the ultimate parent, a programmatic approach is typically required.

6. Experience Cloud (Partner/Customer Accounts).
When a Business Account is enabled as a Partner or Customer account, Salesforce creates up to three portal roles (Executive, Manager, User) for that account. External users see records they own or that are shared via Sharing Sets or Share Groups. Partner Super User Access lets partner users see records owned by other users in the same portal role or below within the same account. Again, none of this cascades through the Account Hierarchy automatically; partner users at a parent account do not automatically see child account data.

Reporting on Hierarchies

Standard report types like Accounts, Accounts and Contacts, or Accounts with Opportunities can filter or group by Parent Account. To report on the entire tree, admins commonly create a custom Ultimate Parent formula or text field populated by Flow and then group or filter by it. Custom report types can also include Parent Account fields via lookup field selection. Roll-ups across the hierarchy are typically done with report summaries or Dashboards rather than native fields.

Common Design Considerations
• Decide on a clear rule for what constitutes a parent (legal entity, billing entity, or sales territory) and document it to prevent inconsistent data.
• Use validation rules or Flows to prevent circular references or excessive depth if business rules require it (Salesforce prevents an account from being its own parent, but deep or inconsistent trees are a data governance issue).
• Use Duplicate Rules and Matching Rules to avoid duplicate accounts that fragment the hierarchy.
• For B2C, evaluate Person Accounts carefully because the decision is irreversible.
• When sharing needs to follow the hierarchy, plan for Account Teams, criteria-based sharing rules on an Ultimate Parent field, Territory Management, or Apex sharing rather than expecting inheritance.

How to Answer Exam Questions on This Topic

Exam questions in this area are almost always scenario-based. Follow this approach:

Step 1: Identify what the question is really testing. Is it about data modeling (how to represent subsidiaries), about visibility (who can see what), or about the Person vs. Business Account decision? Many questions blend these.

Step 2: Separate relationship from access. Whenever a question mentions parent and child accounts and asks about who can see records, immediately recall: hierarchy is a lookup, not sharing. Then look for the answer that uses a legitimate sharing tool.

Step 3: Check implicit sharing before adding complexity. If users have access to an account and need to see its Contacts, Cases, or Opportunities in read-only mode, implicit sharing already handles it. If they need Edit access, you need Account Teams, sharing rules, or OWD changes.

Step 4: Apply the principle of least privilege and least maintenance. Prefer declarative solutions (OWD, role hierarchy, sharing rules, account teams, territories) over Apex unless the scenario explicitly requires logic that declarative tools cannot achieve.

Step 5: Eliminate distractors. Options that say the account hierarchy grants access, that Person Accounts can be disabled, that Contact OWD can be Private with Person Accounts enabled, or that roll-up summary fields can sum across the hierarchy are wrong.

Exam Tips: Answering Questions on Account Hierarchies and Business Account Models

• Tip 1: The Account Hierarchy is created solely through the Parent Account field. If an option mentions a special hierarchy setup object, it is a distractor.
• Tip 2: Hierarchy does not equal sharing. Access to a parent account never automatically grants access to child accounts or vice versa. Pick the answer that uses Sharing Rules, Account Teams, Role Hierarchy, Territory Management, Manual Sharing, or Apex.
• Tip 3: Remember the two directions of implicit sharing: Account access gives Read on child Contacts/Opportunities/Cases; access to a Contact/Opportunity/Case gives Read-Only on its Account. This applies to child records of an account, not to parent accounts in the hierarchy.
• Tip 4: If a question says users need to see all accounts in a corporate family, the strongest declarative answer is usually a custom Ultimate Parent field combined with a criteria-based sharing rule, or Enterprise Territory Management. If the sharing must dynamically follow owner changes across hundreds of trees, Apex managed sharing may be the expected answer.
• Tip 5: Account Teams are the go-to answer when a small, specific group needs varying levels of access (Read vs. Edit) to a particular account and its Opportunities, Cases, and Contacts.
• Tip 6: For Person Accounts, memorize: enabled by Support or Setup, irreversible, requires at least one Account record type, requires Contact OWD = Controlled by Parent, counts toward both Account and Contact storage, uses a dedicated record type. Any option contradicting these is wrong.
• Tip 7: Account OWD choices are Private, Public Read Only, and Public Read/Write. Controlled by Parent is a Contact OWD option, not an Account option.
• Tip 8: No roll-up summary fields across the Account Hierarchy because Parent Account is a lookup. Reports, Flows, or AppExchange apps are the alternative.
• Tip 9: In Lightning, the hierarchy view shows up to 2,000 accounts and columns are configured under Object Manager > Account > Hierarchy Columns.
• Tip 10: Contacts to Multiple Accounts is the answer when a single person must be related to several accounts; it works with Business Accounts, not Person Accounts as the related contact.
• Tip 11: For Experience Cloud scenarios, remember portal roles are per account (up to three), Partner Super User Access expands visibility within the same account only, and Sharing Sets grant access based on the user's Account or Contact lookup, none of which cascade down the Account Hierarchy.
• Tip 12: When two answers both work, choose the one that is declarative, scalable, and lowest-maintenance. The exam rewards the admin-friendly solution over custom code unless the requirement explicitly cannot be met declaratively.
• Tip 13: Read for keywords: parent, subsidiary, corporate family, ultimate parent signal hierarchy modeling; see, edit, visibility, access signal a sharing question; consumer, individual, B2C signal Person Accounts.

Quick Recap

The Account Hierarchy models organizational structure through the Parent Account lookup, supports visual navigation and reporting, and is limited to lookups (no master-detail roll-ups). Business Accounts represent organizations with separate Contacts; Person Accounts merge Account and Contact for individuals and come with permanent configuration constraints. Critically, hierarchy is a data relationship, not a security mechanism. Record access is governed by OWD, Role Hierarchy, implicit sharing, Sharing Rules, Account Teams, Territories, Manual Sharing, and Apex. Master that distinction and the related Person Account prerequisites, and you will handle every hierarchy and account model question the exam presents.