Asset Relationship
An Asset Relationship is a Salesforce standard object that records a non-hierarchical link between two Asset records that exists because of an asset modification, such as a replacement or an upgrade.
Definition
An Asset Relationship is a Salesforce standard object that records a non-hierarchical link between two Asset records that exists because of an asset modification, such as a replacement or an upgrade. It is the object behind the Primary Assets and Related Assets related lists you see on an asset page. When one piece of equipment takes the place of another, the relationship captures which asset replaced which, so the swap is preserved as data rather than living in a note field.
Asset Relationship is used in Field Service, in Revenue Lifecycle Management, and in any business that tracks installed equipment over its life. In Revenue Lifecycle Management it carries a second meaning: it represents assets grouped together in a bundle or set. The object is queryable, reportable, and editable, and it keeps the underlying Asset records untouched while it describes how they relate.
How Asset Relationship tracks equipment changes
What the object actually represents
Salesforce defines Asset Relationship as a non-hierarchical relationship between assets caused by an asset modification, for example a replacement, an upgrade, or another circumstance. That definition is narrower than people assume. It is not a free-form way to link any two assets for any reason. It exists primarily to answer the question, which asset took the place of which other asset, and when. Each record connects two Asset rows and labels the connection with a relationship type. The word non-hierarchical is the key contrast. Asset Hierarchy uses the ParentId field on the Asset object to model containment, meaning one asset sits inside or under another. Asset Relationship sits beside that idea and records a peer-level event between two assets instead of a parent-child structure. Because the link is stored as its own record, it survives even after both assets change status. A decommissioned modem still shows that it was replaced by a newer unit, and the newer unit still shows what it replaced. That history is what makes the object valuable to service teams who need to explain how an installed base reached its current state.
Primary Assets and Related Assets
Most admins meet this object through two related lists rather than through the API. On any asset record you find a Primary Assets list and a Related Assets list. The Primary Assets list shows the assets that replaced the current asset. The Related Assets list shows the assets that the current asset replaced. The direction matters and trips up newcomers, so it helps to read the labels literally. If a customer swaps an old printer for a new one, the old printer record gains an entry in its Primary Assets list pointing at the new printer. The new printer record automatically gains the matching entry in its Related Assets list pointing back at the old printer. You create the link once, from one side, and Salesforce reflects it on both records. There is no need to enter the relationship twice. This two-list design keeps the lineage readable from whichever asset a technician or agent happens to open, which is exactly the moment they usually ask what came before or after a given unit in the field.
The fields on the record
An Asset Relationship record is intentionally small. It carries a lookup to the first asset and a lookup to the related asset, a relationship type that describes the nature of the change, and standard system fields such as owner, created date, and last modified date. The relationship type is the field that gives a row its meaning. Out of the box it expresses the replacement style of relationship that the object was built for, and admins can extend the picklist to fit how their business describes equipment changes. Because the object is a standard object, it also supports custom fields, validation rules, and triggers like most other standard objects. Teams often add fields that record why a replacement happened, who authorized it, or which work order drove it. Keep additions disciplined. The object earns its keep by being a clean, queryable record of asset change, and every extra field is something a report writer and an integration both have to account for later. A short, well-named relationship type picklist usually does more good than a wide set of custom attributes.
Field Service and the installed base
Field Service is where Asset Relationship does most of its work. Service organizations track the equipment they install at customer sites as Asset records, and that installed base changes constantly through repairs, swaps, and upgrades. When a technician replaces a failed component or an entire unit, recording an Asset Relationship keeps the site history accurate. A dispatcher reviewing an account can see that the unit on site today is the third generation of a device that has been replaced twice, which changes how they read the maintenance pattern. Maintenance Plans generate work orders against assets, and a clean replacement history helps teams confirm that plans follow the current asset rather than a retired one. Pairing Asset Relationship with Asset Hierarchy gives the fullest picture. Hierarchy shows what the equipment is made of right now, and relationship shows how individual pieces arrived through past changes. Reporting on both together lets a service manager answer questions about reliability, such as how often a particular model gets replaced within its warranty window, grounded in records instead of anecdotes from the field.
The Revenue Lifecycle Management meaning
The same object carries a second, different meaning in Revenue Lifecycle Management, which is part of Revenue Cloud. There, Asset Relationship represents an asset or assets grouped together in a bundle or set. When a customer buys a bundled product, the resulting assets need to express that they belong together, and the relationship records that grouping. This matters for amendments, renewals, and cancellations, because a change to a bundle should consider every asset in the set rather than one piece in isolation. If a customer cancels a bundle, the grouping tells the system which assets move together. This dual purpose is worth flagging during design. A team that adopts Revenue Lifecycle Management and also runs Field Service shares one Asset Relationship object across two mental models, the replacement lineage model and the bundle grouping model. The relationship type and any custom fields are what keep the two uses from blurring together in reports. Document which records belong to which use so analysts do not accidentally count bundle groupings as equipment replacements when they build dashboards.
Querying and reporting on relationships
Because Asset Relationship is a queryable standard object, you can pull it through SOQL and through the reporting engine. A SOQL query can walk from an asset to its relationship rows and then back to the related assets, which is how an integration reconstructs a full replacement chain. In reports, the usual approach is a custom report type that joins Asset to Asset Relationship and then to the related Asset, exposing both ends of each link in a single row. From there teams build dashboards such as replacements per asset model, replacements per month, or the count of active relationships by relationship type. The reporting payoff depends entirely on the discipline applied at data entry. If relationship type is filled consistently and the direction is recorded correctly, the reports are trustworthy. If records are created inconsistently, the same dashboard becomes misleading. This is why many teams add a validation rule that requires a relationship type and confirm during testing that the Primary Assets and Related Assets directions are populated the way agents expect before they roll the object out to a wider audience.
Sharing, history, and common mistakes
Visibility of an Asset Relationship depends on access to the Asset records it connects. A user who can see both assets sees the relationship, and a user who can see only one of them can hit gaps that feel surprising until you trace the sharing back to the underlying assets. Plan for that when one asset is more tightly restricted than the other. A few mistakes recur in practice. The first is reaching for Asset Relationship to model containment that really belongs in Asset Hierarchy, which produces duplicated and confusing data. The second is confusing the Primary Assets and Related Assets directions, which inverts the replacement lineage and quietly corrupts reports. The third is letting the relationship type picklist sprawl until nobody trusts what the values mean. The fourth is treating the object as a free-form linker between any two assets, when its documented purpose is asset modification in Field Service and bundle grouping in Revenue Lifecycle Management. Keeping the object aligned with those two documented uses, and validating direction during rollout, prevents most of the cleanup work that otherwise lands on an admin months later.
How to record an asset replacement
Record that one asset replaced another by creating an Asset Relationship from the original asset record. You build it once, from the Primary Assets related list, and Salesforce mirrors it onto the replacement asset.
- Create or confirm both Asset records
Make sure the original asset and the replacement asset both exist as Asset records. If the replacement is new equipment, create that Asset first so it is available to link.
- Open the original asset and find Primary Assets
Open the asset that was replaced. On its record page, find the Primary Assets related list, which holds the assets that replaced this one.
- Add the replacement and set the relationship type
Create a new entry in Primary Assets, select the replacement asset, and choose the relationship type that describes the change. Save the record.
- Verify the mirrored entry
Open the replacement asset and confirm the link appears in its Related Assets list pointing back at the original. The direction should read correctly from both records.
The first asset in the relationship, typically the original unit you open to create the record.
The second asset in the relationship, typically the replacement unit you select from the list.
The picklist value describing why the assets are linked, such as a replacement style of change.
- Read the list labels literally. Primary Assets holds what replaced this asset; Related Assets holds what this asset replaced. Reversing them inverts your history.
- You only create the link once. Salesforce populates the matching list on the other asset automatically, so do not enter it twice.
- Do not use this object for containment. If one asset sits inside another, model that with Asset Hierarchy and the ParentId field instead.
Prefer this walkthrough as its own page? How to Asset Relationship in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Asset Relationship.
Hands-on resources to go deeper on Asset Relationship.
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 kind of connection does Asset Relationship model that Asset Hierarchy cannot?
Q2. What does the Relationship Type picklist on Asset Relationship provide?
Q3. How do the Begin Date and End Date fields make an Asset Relationship useful?
Discussion
Loading discussion…