Asset Hierarchy
An Asset Hierarchy is a Salesforce structure that links Asset records into parent and child relationships, so a compound product and its components can be tracked as a single unit.
Definition
An Asset Hierarchy is a Salesforce structure that links Asset records into parent and child relationships, so a compound product and its components can be tracked as a single unit. You build it on the standard Asset object using the Parent Asset field, and Salesforce surfaces the result through the Child Assets related list and a View Asset Hierarchy action that opens a collapsible tree grid.
A common example is a solar panel system that holds a child Asset for each panel, inverter, and meter. An industrial machine can hold child Assets for each replaceable part, and a connected appliance can hold child Assets for its modules. Asset Hierarchy is part of the core CRM schema and is used heavily in Field Service, where a technician servicing one installation needs to know exactly which component failed.
How parent-child asset structures actually work
The Parent Asset field is the link
Every Asset record has a Parent Asset lookup that points back to another Asset on the same object. Setting that lookup on a child record attaches it under its parent, and you can repeat this down several levels to model a real installation. The platform keeps two derived values in step with the structure. Root Asset names the topmost ancestor of any record, and Asset Level records how far down the tree a record sits. Both update automatically as you reparent records, so you do not maintain them by hand. Because the relationship lives on the standard Asset object, it works with the same sharing model, validation rules, triggers, and APIs you already use for Assets. There is nothing extra to install. The Parent Asset field, the Root Asset field, and the Child Assets related list ship out of the box. This matters for adoption, since teams can start grouping components the day they decide their containment model, then refine field-level security and page layouts as the design settles.
Viewing the hierarchy as a tree grid
On any Asset record home page, the dropdown action menu includes a View Asset Hierarchy action. Selecting it opens a collapsible tree grid that shows the parent at the top with its children nested underneath, which Salesforce describes as a way to see related assets as one unit. The Trailhead Field Service content uses a Solar Panel System 4000 with 14 child assets to show the idea. You expand a branch to drill into a subassembly, then collapse it to step back up to the full installation. The Child Assets related list on the parent record gives the same information in a flat list, which is handy for quick edits and for adding new components. The two views answer different questions. The tree grid is for understanding shape and depth at a glance. The related list is for working through children one at a time. Service agents tend to live in the tree grid because it mirrors how a physical product is built, while admins use the related list when bulk-attaching parts during data loads.
Why Field Service leans on the hierarchy
Field Service is the clearest beneficiary of Asset Hierarchy. An asset there represents a specific purchased or installed product, and it links to accounts, contacts, products, cases, work orders, entitlements, and maintenance plans. When a customer reports a fault, the work order can target the exact child component rather than the whole installation, which sharpens parts planning and technician routing. Service history is easier to read too, because cases and work orders sit against the component that actually failed instead of a single catch-all record. Maintenance Plans use the structure as well. A plan attached to a parent can generate work orders for the assets underneath it, so a quarterly inspection covers every part of the system in one pass. None of this requires custom code. The value comes from putting each serviceable part on its own Asset record and connecting it through Parent Asset, so the operational objects that reference Assets immediately gain the same level of detail.
Hierarchy versus Asset Relationship
Salesforce offers a second way to connect Assets, and the two are easy to confuse. Asset Hierarchy through Parent Asset models containment, meaning one asset is physically or logically part of another. The Asset Relationship object models non-containment links, such as one asset that replaced or upgraded another. On a record these relationships appear in the Primary Assets and Related Assets related lists, with a Relationship Type like Upgrade describing the connection. The rule of thumb is simple. If a part lives inside the product, use Parent Asset and let it become a child in the hierarchy. If two assets are peers or one succeeded the other in service, use an Asset Relationship instead. Mixing them produces reports that claim a component is contained when it is really just associated, which erodes trust in the data. Many mature org designs use both deliberately, with the hierarchy describing how a product is built and relationships describing how individual units changed over time.
Reporting and rolling up across children
Because Asset Hierarchy is a self-relationship, you can build a custom report type that joins Asset to itself and exposes every child under its root. That single piece of setup unlocks a range of questions teams ask within days of go-live. How many open cases sit across this whole installation. What is the average age of the components. Which children have warranties expiring this quarter. The derived Root Asset field is the workhorse here, because grouping by Root Asset collapses an entire tree into one row regardless of how deep it runs. Asset Level lets you filter to a particular tier, for example only the top assemblies or only the leaf components. Dashboards then summarize service load or warranty exposure by installation rather than by individual part. The practical advice is to create the hierarchy-aware report type early, since maintenance and field teams will request rolled-up views almost immediately and a flat Asset report cannot answer questions that span parents and children.
Sharing, depth, and data discipline
Two operational gotchas show up again and again. First, access does not flow down the tree on its own. A user who can see a parent installation is not guaranteed to see its children, because the hierarchy is not an ownership relationship. You configure visibility with sharing rules, or you propagate it with Apex managed sharing when the logic is complex. Field Service teams hit this when a technician can open the root record but not the failed component. Second, depth has a practical ceiling. The platform supports many levels, but SOQL that walks Parent Asset across several tiers gets slower and harder to maintain, so most production designs cap real depth at four or five levels. A tree that tries to model every screw signals a modeling problem, and those lowest levels often belong on a different object such as a part or attribute record. Consistent depth across customers matters too, since uneven trees make cross-installation reports fragile. Decide which level holds the warranty and which level work orders target, then enforce that pattern during data entry.
Build an Asset Hierarchy from parent to child
You create an Asset Hierarchy by setting the Parent Asset field on the records that should sit beneath a parent. There is no separate hierarchy object to enable. Build the parent first, then attach children to it.
- Create or open the parent Asset
Make sure the top-level installation exists as an Asset record, for example the full machine or system. This record becomes the root of the tree and usually carries account, product, and warranty details for the unit as a whole.
- Create the child Asset
Add an Asset for each serviceable component. Give it a clear name and link it to the same account and the relevant product so reports and work orders read cleanly later.
- Set the Parent Asset lookup
On the child record, populate the Parent Asset field with the parent you created in step one. Salesforce derives Root Asset and Asset Level automatically once the link is saved.
- Verify with View Asset Hierarchy
Open the parent record, use the View Asset Hierarchy action, and confirm the child appears nested underneath in the collapsible tree grid. The Child Assets related list on the parent should list it too.
A descriptive label for each record. Use names that identify the component, since the tree grid and related lists display this value.
The lookup on the child Asset that points to its parent. This single field is what creates the hierarchy.
The product the asset represents. Recommended on every record so hierarchy reports can group and filter by product.
- Root Asset and Asset Level are derived. Do not try to set them manually; they recalculate when you change Parent Asset.
- Granting a user access to the parent does not grant access to children. Configure sharing rules so service users can see the components.
- Keep practical depth to about four or five levels. Very deep trees slow SOQL that traverses Parent Asset and complicate reporting.
- Use Parent Asset for containment only. For replacement or upgrade links between peer assets, create an Asset Relationship instead.
Prefer this walkthrough as its own page? How to Asset Hierarchy in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Create Asset HierarchiesSalesforce
- Asset | Object Reference for the Salesforce PlatformSalesforce
Straight from the source - Salesforce's reference material on Asset Hierarchy.
- Create Asset HierarchiesSalesforce
- Relationships Between AssetsSalesforce
Hands-on resources to go deeper on Asset Hierarchy.
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. Which field on the Asset object builds an Asset Hierarchy?
Q2. What does Salesforce derive automatically once ParentId is set in an Asset Hierarchy?
Q3. Why do most production Asset Hierarchy designs cap practical depth around four or five levels?
Discussion
Loading discussion…