Asset Hierarchy
Asset Hierarchy is the Salesforce feature that lets Asset records form parent-child relationships through the ParentId field, modelling physical or logical containment between assets.
Definition
Asset Hierarchy is the Salesforce feature that lets Asset records form parent-child relationships through the ParentId field, modelling physical or logical containment between assets. A solar installation Asset might have a child Asset for each panel; an industrial machine might have child Assets for each component; a software entitlement might have child Assets for each licensed seat. The hierarchy is shown on the Asset Lightning page through the Asset Hierarchy related list and is queryable as a self-referencing tree. Asset Hierarchy is essential to Field Service, IoT, and any industry that services compound products where the parent's repair history depends on knowing which child component failed.
Asset Hierarchy is part of the standard Asset object's schema. Salesforce ships ParentId, Root Asset, Hierarchy Level, and Asset Hierarchy related list out of the box. Field Service Lightning uses the hierarchy to roll up service history, propagate maintenance plans, and route field technicians to the right component within a larger installation. Salesforce Industries solutions (Energy, Manufacturing, Communications) extend the schema with industry-specific fields and dashboards, but the underlying parent-child mechanism is the same. Most production usage of Asset Hierarchy involves a careful initial data model decision (how deep, how broad, which level holds the warranty) and consistent data entry discipline thereafter.
How Asset Hierarchy supports real-world product structure
The ParentId self-relationship
The standard Asset object has a ParentId field that lookups back to Asset. Setting ParentId on a child Asset attaches it to its parent. Salesforce automatically derives Root Asset (the topmost ancestor) and Hierarchy Level (depth from root). Both are queryable, which lets reports group child assets under their root.
Field Service use cases
Field Service Lightning relies heavily on Asset Hierarchy. A service appointment may target the root Asset, but the technician needs to know which child component is faulty. Maintenance Plans propagate to children when configured; the child's next service date is computed from the plan attached to the parent.
Industries solutions and Asset Hierarchy
Salesforce Industries Energy, Communications, and Manufacturing solutions extend Asset Hierarchy with industry-specific child types and dashboards. An Energy installation models meters, panels, and inverters as children. A Communications subscriber assignment models the modem, the routers, and the connected devices.
Reporting on rolled-up data
Custom report types that join Asset to itself through ParentId expose the full hierarchy. Reports often answer questions like Total Service Cases on this installation, Average Age of Components, or Warranty Expiration Across All Children. Building the report type once enables many dashboards.
Sharing implications
Asset Hierarchy does not automatically cascade sharing. A user with access to the parent Asset is not guaranteed access to the children. Sharing rules need to be configured explicitly or sharing inheritance set up through Apex Managed Sharing. Field Service teams routinely hit this when a technician can see the root installation but not the specific component.
Performance and depth constraints
The platform supports deep hierarchies, but queries that walk many levels of ParentId via SOQL can run slow or hit governor limits. Most production designs cap practical depth at four or five levels. Deeper hierarchies usually indicate a modelling problem; consider whether the lower levels belong on a different object.
Hierarchy and the Asset Relationship object
Asset Relationship is a complementary feature that models non-hierarchical connections between Assets (a router is associated with a modem but not contained by it). Use ParentId for containment, Asset Relationship for peer associations. Mixing the two produces confusing reports.
Common modelling pitfalls
Three patterns recur. Too-deep hierarchies that try to model every screw lead to performance issues and unwieldy reports. Inconsistent depth across customers makes reporting fragile. Treating Asset Hierarchy as a substitute for Asset Relationship results in containment claims that do not match real-world structure.
How to model Asset Hierarchy effectively
Asset Hierarchy is mostly a data model decision. The choice of depth, level names, and which fields hold what data drives years of downstream reporting and field-service behaviour.
- Define the levels you want to model
Map the real-world product structure: Installation, Subsystem, Component. Cap at three to five levels; deeper hierarchies usually mean the data belongs on a different object.
- Configure ParentId visibility and required-status
Add ParentId to the page layout and set it as required for child-level Record Types. Without the layout placement, users cannot establish the hierarchy from the UI.
- Configure the Asset Hierarchy related list
Drop the Asset Hierarchy component on the Asset Lightning record page. Users see the hierarchy view inline; the tree visualisation is far more usable than a flat related list.
- Set up sharing inheritance
Build sharing rules or Apex Managed Sharing logic that propagates access from parent to children. Without explicit sharing, users with parent access cannot see children.
- Build hierarchy-aware reports and Maintenance Plans
Create custom report types that join Asset to itself through ParentId. Configure Maintenance Plans on root assets and let them propagate to children where applicable.
- Sharing does not cascade automatically. Users with parent access do not see children without explicit sharing rules.
- Deep hierarchies hit performance limits. Cap practical depth at four or five levels; deeper usually indicates a different object would be a better fit.
- ParentId must be in the page layout for users to set it from the UI. Without layout placement, hierarchy can only be set through data loaders or Apex.
- Asset Hierarchy is containment; Asset Relationship is peer association. Confusing the two produces reports that imply structure that does not exist.
Trust & references
Cross-checked against the following references.
- Asset HierarchySalesforce Help
- Field Service OverviewSalesforce Help
Straight from the source - Salesforce's reference material on Asset Hierarchy.
- Asset API ReferenceSalesforce Developer Docs
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Asset Hierarchy allow?
Q2. Which industry commonly uses Asset Hierarchy?
Q3. Why is each Asset in a hierarchy still a distinct record?
Discussion
Loading discussion…