Salesforce Asset Lifecycle Management for Connected Devices

Short answer: Asset lifecycle management on Salesforce works when the installed unit is one Asset record that service, warranty and renewals all read, rather than three records in three teams. Salesforce already gives you the objects for it: Asset with a parent hierarchy, WarrantyTerm and AssetWarranty for coverage, and Entitlement or ServiceContract for what the customer bought. The hard part is telemetry, because device events must not land in the org row by row.

What does asset lifecycle management mean on Salesforce?

It means tracking a physical unit from shipment through installation, service, warranty claims, upgrades and replacement, on one record that carries its own history. Salesforce packages this as Asset Service Lifecycle Management, which adds an interactive asset hierarchy, an asset coverage view for entitlements, work order estimation and product service campaigns for recalls and upgrades (Salesforce Help).

The features are the easy part. What decides whether any of it works is the data model you commit to in week one.

Which object should hold what?

Most failed connected-asset programmes we are called into failed here, not in the integration. A clean split looks like this.

• Product2 is the model. It is what you sell, not what the customer has.
• Asset is the individual unit: serial number, install date, status, account, contact and location. Use the parent and root asset fields to model a device that sits inside a gateway, a panel or a building, so a fault on a component rolls up to something a technician can be dispatched to.
• WarrantyTerm defines what is covered, meaning labour, parts and expenses, and AssetWarranty attaches that term to a specific unit with its own dates (object reference).
• Entitlement and ServiceContract carry what the customer bought and until when. Entitlements can hang off the account, the asset, the case or the contract, which is exactly why teams end up with the same coverage recorded in three places.
• Case and WorkOrder reference the asset, never the product. A case without an asset id is a case you cannot bill, cover or trend.

One rule keeps this honest: coverage is asserted in exactly one place, and everything else reads it. If sales can edit a renewal date that service does not see, you do not have asset lifecycle management, you have three spreadsheets in a trench coat.

How do you get device telemetry in without drowning the org?

Salesforce retired IoT Explorer and pointed customers at platform events and flows instead (retirement notice). That is the right instinct, but it needs a rule attached: Salesforce stores state and decisions, not the raw stream.

In practice we run three layers.

1. Ingest and reduce outside the org. Heartbeats, readings and duplicate alarms are collapsed into meaningful transitions before anything crosses the API boundary.
2. Publish transitions as platform events. One event per state change, carrying the serial number, the condition and the timestamp, resolved to the Asset by serial rather than by record id.
3. Write derived state onto the Asset, and let automation decide. Current health, last seen, firmware version, open fault. A flow or Apex handler then decides case, work order, or nothing at all.

That last option matters most. The triage rule, not the ingestion, is what keeps a connected fleet serviceable. For ASSA ABLOY, across FocusCura and Phoniro, we run 11,000 connected devices producing up to 2.5 million events a week and cut weekly cases from 3,000 to 350, a 93% reduction across three markets with no added support staff. The devices did not get quieter. The model stopped creating a case for every symptom.

What does one asset record actually buy you?

• Service sees coverage before dispatch, so nobody sends a paid technician to a unit under warranty.
• Warranty claims resolve against the term attached to that unit, not against a policy someone remembers.
• Renewals are forecast from install dates and warranty end dates that are already in the system, so expiries stop being discovered by the customer.
• Product teams get failure rates per model and per firmware version, because every case points at a real unit.

None of that needs an AI layer to be worth doing. It does make the AI layer possible later, because an agent can only reason about an installed base that is actually modelled.

How should you sequence the build?

1. Load the installed base with real serial numbers and install dates, even if it is partial. Assets without serials cannot be reconciled later.
2. Model the hierarchy before automating anything, because rework here touches every downstream record.
3. Attach warranty terms and entitlements, and pick the single object that owns coverage.
4. Wire telemetry as state transitions, with a written triage rule per condition.
5. Only then add work orders, service contracts, renewal forecasting and agents.

Teams that reverse steps one and four end up with a beautiful integration writing events onto assets nobody trusts. If you want this reviewed against your own org, Tekunda does asset lifecycle work on Salesforce alongside Field Service and connected-device delivery.

FAQ

Should each device be an Asset or a custom object?

Asset, in almost every case. Entitlements, warranties, work orders and Field Service already relate to it, and a custom object means rebuilding those relationships by hand.

Where should raw telemetry live?

Outside the transactional org, in a store built for time series. Salesforce should hold current state, the events that changed it and the decisions taken, not every reading.

How do warranty and entitlement differ?

A warranty term describes what is covered on a unit, such as parts, labour and expenses. An entitlement or service contract describes what the customer has bought, including support levels and dates. Most organisations need both.

Can we do this without Field Service?

Yes. Asset, warranty and entitlement modelling works in Service Cloud alone. Field Service becomes necessary once you are dispatching technicians, managing parts and scheduling maintenance visits.