Salesforce Asset Lifecycle Management for Connected Devices

Short answer: Salesforce Asset Service Lifecycle Management (ASLM) is Salesforce's packaged set of features for servicing a physical asset from installation to retirement: an interactive asset hierarchy, a coverage view of entitlements, work order estimation, recall and upgrade campaigns, exchanges, depot repair and service inventory, all built on the standard Asset object. It works when each installed unit is one Asset record that service, warranty and renewals all read. For connected devices, the hard part is telemetry, because device events must not land in the org row by row.

What is Salesforce Asset Service Lifecycle Management?

Salesforce describes ASLM as a way to "manage the entire lifecycle of asset service operations" (Salesforce Help). In practice it groups into five capability areas:

• Asset visibility. Asset Interactive Hierarchy shows parent and child assets, and Asset Coverage View puts a customer's entitlements in front of the agent.
• Service execution. Work Order Estimation prices work before it starts, Book Service Appointment handles scheduling, and Product Service Campaign runs large-scale recalls and upgrades.
• Returns and repair. Advanced Exchange creates return and replacement requests, Depot Repair handles units sent back for repair, and Service Parts Return covers damaged parts tied to work orders.
• Service inventory. Inventory allocation, batch management, search and transfer, counts and replenishment.
• Labour and AI. Timesheets and Labor Cost Optimization, plus Agentforce for ASLM, which provides agent templates for inventory tasks and service estimation.

The short version: standard Salesforce gives you the asset and its coverage, and ASLM adds the service operations that run around it.

Which clouds and licences does ASLM need?

According to the same Help article, ASLM is available in Lightning Experience in Service Cloud, Manufacturing Cloud, Automotive Cloud, Communications Cloud, Consumer Goods Cloud, Energy and Utilities Cloud and Media Cloud. Some features need add-on licences, bought through Salesforce Go, so check the editions table for each feature before you plan around it.

Two related products are easy to confuse with it. When Salesforce announced ASLM in June 2024 as a separate add-on, it also announced Connected Assets, a separate add-on for acting on two-way telematics events such as firmware updates, work order creation or safety alerts, and an Asset Health Score for Field Service (Futurum Group). ASLM is the service layer. Connected Assets and your own integration are the telemetry layer.

Which object should hold what?

None of those features help if the data model underneath is wrong. 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. This is also what the interactive hierarchy draws.
• 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, and why the coverage view shows conflicting answers.
• 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. The integration user that publishes them usually authenticates through a connected app, so review it against the Salesforce connected app security changes before go-live.
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. The full breakdown is in how connected-device teams cut support cases by 93 percent on Salesforce.

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.
• Recalls and upgrades target the right units, because a product service campaign can only reach assets that carry a real model, serial and firmware version.
• 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 switch on ASLM features such as estimation, campaigns and exchanges, along with 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, see how Tekunda delivers asset lifecycle management on Salesforce alongside Field Service and connected-device work.

FAQ

What is Salesforce Asset Service Lifecycle Management in one line?

It is a set of Salesforce features for servicing installed assets end to end, from hierarchy and coverage to estimates, recalls, exchanges, repair and service inventory.

Should each device be an Asset or a custom object?

Asset, in almost every case. Entitlements, warranties, work orders, ASLM 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.