Field Service assets: maintenance, parts and partners

For a machine builder, Salesforce Field Service works best with a flat installed base: the machine and the assemblies with their own serial number, maintenance or warranty become assets, everything else stays in PLM. A maintenance contract spreads across service contract, maintenance plan and entitlement. Maintenance runs by calendar, by operating hours or by criteria such as “2,000 hours or 12 months”, fed by a daily counter from the ERP or the IoT platform. The ERP keeps spare parts stock, Field Service holds a copy for the vans. Service partners get one resource per technician and one territory per company. Add-ons come last.

How deep should the installed base go?

Field Service, which Salesforce sells today as Field Service and Operations (opens in a new tab), hangs almost everything in this chapter on the asset. Chapter 3 covered how technicians document their work; this one covers what they document it against.

An asset is a product bought or installed at a customer, linked to an account, a contact or both. The Parent Asset field builds the hierarchy. The Field Service limits (opens in a new tab) in Salesforce Help allow 2,000 child assets per asset, 50 levels and 10,000 assets per hierarchy, while the tree grid view shows hierarchies of up to 500 assets.

Those limits rarely matter. Depth costs you earlier, in data upkeep, maintenance plans and on the tablets. My rule of thumb has three questions, and one yes makes a component an asset:

Question	Why it matters
Own serial number?	The technician has to record which gearbox or robot was installed or exchanged.
Own maintenance?	Maintenance work rules hang on assets, so a spindle with its own interval needs one.
Own warranty?	A bought-in part whose warranty starts on a different date than the machine’s.

Everything else stays in the PLM parts list. For most machines that leaves two or three levels. The calculation for a packaging line with 6 machines, 40 serialised assemblies and 900 parts is in asset hierarchy: how deep for a machine?.

Two decisions come before the first ERP load. First, values that differ per series, such as a firmware version, go into asset attributes. The AssetAttribute object (opens in a new tab), available since API version 57.0, stores a value per asset against an attribute definition, so a new machine series needs no new custom field. Counters that drive maintenance stay number fields on the asset. Second, someone owns the tree after delivery. The ERP delivers the installed base, but a year later a technician exchanges a gearbox. One system has to lead from then on, or nobody trusts the tree.

Check serial numbers and locations before maintenance plans build on them.

Service contract, maintenance plan, entitlement: one object per job

A maintenance contract does not live in one object. In Field Service it is split three ways:

Object	Answers	Example
Service contract with contract line items	What was sold, for which assets	Three-year contract for a production line
Maintenance plan with maintenance work rules	When planned maintenance happens	Service every 2,000 operating hours
Entitlement with entitlement process and milestones	What the customer is entitled to, and whether it was met	Technician on site within 24 hours

The maintenance plan creates work orders in advance. The entitlement matters for breakdowns: according to Trailhead (opens in a new tab), entitlement processes only run on records that match their type, so work orders need their own process of type Work Order. A flow can then raise the priority of a work order with a committed response time, and the engine schedules it first. How the three objects work together, including the priority logic, is in how to model maintenance contracts.

The commercial side is a separate question. If you sell maintenance contracts as subscriptions and invoice them quarterly, Revenue Cloud can handle the billing, while Field Service knows nothing about those subscriptions. The handover between the two is described in maintenance contracts: recurring billing in Revenue Cloud and in the Revenue Cloud chapter on billing and usage-based pricing.

Calendar or operating hours: which trigger fits?

A six-month calendar fits badly when the same machine runs one shift at one customer and three at another. According to Salesforce Help on preventive maintenance (opens in a new tab), maintenance work rules can also work with usage and criteria:

Rule type	Reads	Fits
Calendar-based	An interval in days, weeks or months	Statutory inspections, fixed contract dates
Usage-based	A usage field on the asset, which may be a formula, and a next occurrence field the system updates	Operating hours, cycles, strokes
Criteria-based	Recordset filter criteria on asset fields	Thresholds and “whichever comes first”

Three details shape the design. A criteria-based rule creates no new work order while its last one is still open, according to the help page on criteria-based maintenance (opens in a new tab). The same page shows that a criteria rule and a calendar rule generate work orders independently, even with the same suggested date, so “2,000 hours or 12 months” belongs in one rule with OR logic. And the condition has to reset after the visit, for example with a flow that stores the counter reading when the work order closes.

The limits that matter: one generation run creates at most 2,600 work orders and line items per plan, a plan with a count-based rule takes at most 2,000 assets, and Salesforce recommends no more than five maintenance work rules per plan or asset.

2,600

work orders and line items at most per plan and generation run

2,000

assets at most in a plan with a count-based rule

5

maintenance work rules at most per plan or asset, as Salesforce recommends

I split plans by series or region so each stays well below that and has an owner.

The counter comes from the IoT platform, the ERP or the technician on site, and a daily value is enough. The setup step by step, including the reset flow, is in usage-based maintenance in Field Service.

When is predictive maintenance realistic?

Predictive maintenance needs a service history more than it needs sensors. Salesforce announced Asset Service Prediction in June 2024 (opens in a new tab) as an AI model that predicts when and why an asset may fail, based on current asset data and the service history of similar assets, with an open beta planned for that winter. The current asset management page (opens in a new tab) describes it without a status, so ask for availability in your edition in writing.

The model learns only from what your work orders contain. Without serial numbers on corrective work orders and coded failure causes, I recommend the usage and criteria rules above plus a few aggregated condition signals.

Machine data costs money once it lands in Data 360. The Flex Credits rate card of 31 August 2026 (opens in a new tab) prices the Streaming Pipeline at 3,500 credits per million rows in the base tier, and 15-minute aggregates have 900 times fewer rows than one-second readings. Raw time series belong in the IoT platform or historian. The data check and the full cost calculation are in predictive maintenance in Salesforce: what data you need.

Do you need Asset Service Lifecycle Management or Connected Assets?

Usually not at the start. Assets with hierarchies, maintenance plans, service contracts and entitlements are part of core Field Service. The price list (opens in a new tab) (October 2026) shows two asset add-ons:

Add-on	List price	What it brings
Asset Service Lifecycle Management	$75 per user and month	The ASLM section in Salesforce Help (opens in a new tab) lists, among others, the Asset Coverage View, the Asset Interactive Hierarchy, work order estimation, product service campaigns, depot repair, advanced exchange, inventory functions and timesheets.
Connected Assets	$15,000 per org and month, so $180,000 a year at list price	Telemetry, the Asset Health Score and 10,000 connected digital assets.

Several ASLM functions handle stock, such as counts and replenishment; if SAP owns stock, they create a second truth. For a machine builder I see the fit in what the ERP does poorly on the service side: coverage at the hotline, repair quotes, retrofit campaigns and depot repair. The comparison of add-on and own build for 30 users is in Asset Service Lifecycle Management: worth the add-on?.

Spare parts: the ERP keeps the stock

In the ERP a spare part has a value, a purchasing process and postings to accounting. Field Service only needs quantities per location. According to the inventory data model (opens in a new tab), a product item holds the stock of one part at one location, products required list what a job needs, and products consumed record what was used, with the product item quantity updated automatically. A location (opens in a new tab) can be a warehouse or a service vehicle.

The ERP sends material master and stock, Salesforce sends back consumed parts and part requests. Bring only the vans and the warehouses that restock them into Salesforce. 40 vans with 300 parts each are already 12,000 product items, and every one of them ends up offline on a device. Which data the app should hold offline is in Field Service mobile offline, the split of tasks in spare parts: ERP or Salesforce?.

Many spare parts calls need no visit. If customers order a known part for their machine themselves, the hotline has less to do; the B2B Commerce chapter on catalogue, search and entitlements shows how parts per machine become visible in a store.

Where does warranty belong?

Warranty touches three products, so decide the owner first:

Product	What it brings for warranty
Field Service	Warranty terms and asset warranties in its warranty management data model (opens in a new tab)
ASLM	Coverage views and campaigns
Manufacturing Cloud	Warranty Lifecycle Management (opens in a new tab) with warranty terms at several product levels and claims that partners and distributors submit through a portal

My rule: if dealers submit warranty claims, Manufacturing Cloud owns warranty, as described in the Manufacturing Cloud chapter on warranty and after-sales. If only your own technicians need to see coverage when a visit is booked, the entitlement on the asset is enough and claims stay in the ERP. Two warranty models on the same asset give two answers to the same customer.

Service partners work in the same process

Partners belong in the same process as your own technicians: same plan, same app, same service report. Salesforce’s architecture guide on contractor sharing (opens in a new tab) describes two models. A named contractor is treated much like an employee and needs a user licence of their own. A contractor company can be modelled as a capacity-based resource, and the partner assigns its own people. The guide uses the service territory as the main security boundary, with a child territory per contractor company.

I prefer the first model for regular partners and the second for partners who step in at peaks. Contractor Plus costs $80 per user or $32 per login and month according to the price list, so per user wins above 2.5 logins a month. Roles and licence rules are in Field Service licences by role, the setup and what stays deliberately different in how to bring in service partners.

Worked example: 1,200 machines in three series

A builder of machining centres has 1,200 machines in the field in three series. The service contract says: service every 2,000 operating hours or every 12 months, whichever comes first. 700 machines are connected, 500 are not. Two partner companies cover Scandinavia.

Area	Decision in the scenario
Installed base	Each machine has six serialised assemblies: 8,400 assets in two levels, loaded from SAP. Technicians record exchanges in the app, and SAP stays the master.
Maintenance	One criteria-based rule per machine with two conditions joined by OR. The IoT platform writes hours every night, technicians enter the reading for unconnected machines. Six plans, one per series and region, with at most 250 machines each.
Effect	Assume 300 machines run two shifts at about 4,000 hours a year and get two services, while 900 single-shift machines fall back to the 12-month condition. That is 1,500 visits a year instead of 2,400 with a fixed six-month calendar.
Parts and partners	30 vans in Salesforce as locations, stock synced nightly from SAP. The two partners get a territory each, regular technicians on Contractor Plus per user.
Add-ons	None in the first year. Connected Assets would cost $180,000 a year without changing a single decision.

Set the asset depth per machine type

Decision	What it covers
Asset depth per machine type	Set with the questions above, plus which system leads the installed base after delivery.
Contract types	Each with its objects: what was sold, which maintenance, which response time.
Counter source per series	Where the counter comes from and which rule wins when the ERP and the technician disagree.
Stock ownership	Which system owns stock and which locations go into Salesforce.
Warranty owner	Field Service, ASLM or Manufacturing Cloud.
Partner model	One per partner company.

Most of these are interface questions, which I work on in Salesforce integration. Chapter 5 adds AI agents, rollout and operations; the overview page lists all chapters.