The Asset object records what a specific customer actually owns — this product, this serial number, this account, with dates. Use it when support needs to know what is installed, when renewals depend on what was sold, or when you need a hierarchy of components. Do not use it as a second opportunity line item table, which is the most common way it goes wrong.
What an Asset is
An Asset links a Product2 to an Account (and optionally a Contact), with purchase and install dates, quantity, price, status and a serial number. It represents an instance of a product in the customer’s possession, as distinct from a line on a deal.
| Object | Answers |
|---|---|
Product2 |
What do we sell? |
OpportunityLineItem |
What did we agree to sell, on this deal? |
Asset |
What does this customer have right now? |
Contract / Entitlement |
What support are they owed for it? |
The distinction that matters: a line item is historical and immutable in spirit — it records an agreement. An asset is current state and changes over its life. Conflating them produces a model where correcting today’s reality rewrites the sales history.
Asset hierarchies
Assets support a parent-child relationship through ParentId, plus a root asset reference, so you can model a system and its components: a machine with modules, a subscription with add-ons, a vehicle with fitted parts.
This is genuinely useful for support, where the question “what is this customer running” needs the whole tree rather than a flat list. Two cautions:
- Depth has a ceiling. Asset hierarchies are limited in how deep they can nest, so a model that needs arbitrary depth does not fit.
- Roll-ups are not automatic. Summing child asset values onto the parent is work you do, not something the hierarchy gives you.
When to create assets
The common trigger is closing an opportunity: line items become assets. That is reasonable and it is where most implementations put the automation.
Be deliberate about three things before you build it:
One asset per unit, or one per line? A line for five licences can be one asset with quantity five, or five assets. Serial-numbered physical goods need one each. Licences usually do not. This decision is very hard to reverse once data exists, so make it explicitly rather than by accident.
What happens on amendment? When a customer upgrades, does the existing asset change status and a new one get created, or does the existing one update? Both are defensible. Only one can be true in your org, and support and renewals both depend on which.
Who owns lifecycle? Assets that are created and never updated become a list of everything ever sold, which is not what the object is for and is worse than useless because people trust it.
Status, and keeping it honest
The Status field carries values like Purchased, Shipped, Installed, Registered and Obsolete. It is the field that makes the object worth having, and it is the field that rots first.
If nothing in your process updates status, every query has to guess. A report of “installed base” that includes decommissioned equipment sends field engineers to sites that returned the product two years ago.
So: before building asset creation, decide what updates status, and build that at the same time. Creation without lifecycle is the failure mode here, not an incomplete first phase.
Assets and Cases
Case has an AssetId field, and this is where the object earns its place. A support agent seeing the exact asset (with install date, version and warranty dates) is answering a different quality of question than one seeing only the account.
It also makes genuinely useful reporting possible: cases per asset, failure rates per product version, time-to-failure since install. Those are analyses the line-item model cannot support, because a line item does not know whether the thing is still in service.
Where teams get it wrong
Using assets as a renewal engine. Assets record possession. They are not a subscription billing model. If you need terms, proration and scheduled renewals, that is contracts, or a revenue product, or a custom object — not Asset with extra fields bolted on.
Creating assets for everything sold. A consumable sold monthly does not need an asset per shipment. Assets are for things with an identity that persists and a state worth tracking.
No account relationship discipline. Assets belong to an account, and when the account is merged or the customer reorganises, the assets need to move. Plan for it, because customer reorganisations are routine.
Skipping serial numbers because “we do not have them”. If the thing genuinely has no identity, ask whether you need an asset at all rather than creating thousands of indistinguishable rows.
Frequently asked
Do assets have to come from opportunity products?
No. They can be created by an integration from an ERP, by support, or manually. Opportunity closure is the most common trigger, not a requirement.
Can an asset belong to a contact rather than an account?
Asset supports both an account and a contact reference, which matters in business-to-consumer models. Decide which is authoritative in your org and be consistent.
Is Asset the right object for software licences?
It can be, for tracking entitlement to a version. For subscription lifecycle with terms and renewals, a contract or subscription model usually fits better.
How deep can asset hierarchies go?
There is a documented limit on nesting depth, so check it before designing a deep structure. Most real models are two or three levels.
What is the difference from Product Consumed in Field Service?
Field Service has its own objects for parts consumed on a work order. Asset represents the installed thing. Product consumed represents what was used servicing it.
Reference: Object Reference for the Salesforce Platform. Asset; Assets and Asset Hierarchies, Salesforce Help.
