Usage-based maintenance in Field Service: hours, not dates

In Salesforce Field Service you trigger maintenance by operating hours with maintenance work rules that read a counter on the asset instead of a calendar date. There are two variants. A usage-based rule reads a usage field on the asset, which may be a formula, and the system keeps a next occurrence field up to date. A criteria-based rule uses filter criteria, for example “cumulative downtime of 1,000 hours or more”, and creates a work order when they are true. The counter comes from the ERP or the IoT platform once a day. Raw sensor data stays outside Salesforce.

Calendar, usage or criteria: which trigger fits?

Most maintenance plans start with the calendar: inspection every six months. For machines that run one shift at one customer and three shifts at another, that is wrong twice. The light user gets visits it does not need, the heavy user waits too long.

Field Service knows three kinds of maintenance work rules, described on the help page on preventive maintenance1:

Rule type	Reads	Typical use
Calendar-based	Interval in days, weeks, months	Statutory inspections, fixed contract dates
Usage-based	A usage field on the asset and a next occurrence field	Operating hours, cycles, strokes
Criteria-based	Recordset filter criteria on asset fields	Thresholds, combined conditions, “whichever comes first”

Recordset filter criteria are a saved set of conditions on asset fields, such as “operating hours since last service is greater than or equal to 2,000”. The basics of maintenance plans, service contracts and entitlements are covered in how to model maintenance contracts.

How does a usage-based rule work?

The rule points to two fields on the asset. The usage field holds the counter, for example operating hours. According to Help, it may be a formula, so you can calculate it from other asset fields. The next occurrence field holds the point at which the next maintenance is due. It may not be a formula, because the system updates it itself.

That means: one number field per counter type on the asset, filled from outside, plus one system-maintained field per rule. The overview page names the fields but does not spell out every step of the calculation, so I test it in a sandbox with a few real counter readings before the first plan goes live.

Criteria-based rules create no second open work order

You create recordset filter criteria with conditions on standard or custom asset fields, choose whether all must be true or at least one, and attach them to a maintenance work rule of type criteria-based. Help’s own example combines 60,000 activations or six months since the last overhaul with OR logic. That is exactly the “whichever comes first” pattern machine builders write into their service contracts.

Three rules from Help shape the design:

• One open work order at a time. While a generated work order is not completed, the rule creates no new one. Cannot Complete, Canceled, Completed and Closed count as completed.
• The condition must reset. If the condition is still true after completion, the next run creates another work order. Help’s example: cumulative downtime rises from 982 to 1,024 hours, a work order is created, and because the value stays above 1,000, the next one follows. Compare against “hours since last service”, and store the counter reading at completion, for example with a flow when the work order closes. Help suggests the same: update a custom field as work orders finish.
• Field types. URL, multi-select picklist, encrypted and text area fields cannot be used, and currency fields cannot define filter criteria. Counters belong in number fields.

Help also mentions asset attributes as a way to track values such as activations since the last overhaul. The AssetAttribute object2 exists since API version 57.0. Why I use attributes for some values and fields for others is in Field Service asset hierarchy: how deep for a machine?.

One permission detail: the Maintenance Work Rule and Recordset Filter Criteria objects need the same access and sharing, otherwise rules stop working for some users.

Where does the counter come from?

Help names three sources: maintained by hand, updated by an IoT platform, or through an integration from AppExchange. For a machine builder that usually means:

• The IoT platform writes the operating hours of connected machines once a day.
• The ERP, for example SAP, sends counter readings it already gets from the customer or from service reports.
• The technician reads the counter on site and enters it in the mobile app. For unconnected machines, that is the only source.

A daily value is enough. A maintenance interval of 2,000 hours does not need minute-level data, and 1,200 counter updates a day are a small interface. The raw time series stay in the IoT platform or historian, as described in predictive maintenance in Salesforce: what data you need. Decide which source wins when two disagree, for example when the technician reads 2,140 hours and the ERP still shows 1,980. Like every master data question, this needs one leading system per field, as in what data scheduling needs. The interface itself belongs on the Salesforce integration list.

The limits: 2,600 work orders per run, 2,000 assets per plan

The Field Service limits3 that hit usage-based plans first:

2,600

Work orders and line items combined, at most per maintenance plan and generation run

2,000

Maintenance assets, at most in a plan with a count-based work rule

5

Maintenance work rules per plan or asset, at most (Salesforce recommendation)

365 days

Generation horizon, at most

Help gives 2,600 assets per plan as the practical limit, less than 1,300 with two rules per asset and less than 650 with four. The generation timeframe is at most 20 years.

In practice I split plans by product series or service region. That keeps every plan below the limits and gives each one an owner.

Worked example: 1,200 compressors

The figures are assumed. A compressor manufacturer services 1,200 units in the field under contract. The contract says: service every 2,000 operating hours or every 12 months, whichever comes first. 800 units are connected, 400 are not.

Data. Each asset gets a number field for operating hours, a field for the reading at the last service and a date of the last service. A formula calculates hours since the last service, a second one the months. The IoT platform writes the hours of the connected units every night. For the other 400, technicians enter the reading at every visit, and the 12-month condition carries them.

Rule. One criteria-based rule with two conditions joined by OR. A flow writes the reading and the date to the asset when the work order is completed, which resets both conditions.

Plans. Three plans by region with about 400 assets each, well below 2,600 work orders per run.

Effect. Assume half the connected units run two shifts at about 4,000 hours a year: they get two services a year instead of one. Single-shift units at 1,800 hours a year fall back to the 12-month condition. Compared with a fixed six-month calendar for all 1,200 units, that is 1,600 instead of 2,400 visits a year, and the heavily used compressors still get theirs on time.

First step: one series with ten assets in a sandbox

Pick one series and write down the interval from the contract in one sentence. Check where the counter lives today and how often it is updated. Then model the fields, one criteria-based rule and the reset flow in a sandbox, and test with ten real assets before you move the whole series. The masterclass chapter on assets, maintenance and parts shows where this fits next to contracts, spare parts and service partners.

Sources3

1. 1preventive maintenance (opens in a new tab)help.salesforce.com
2. 2AssetAttribute object (opens in a new tab)developer.salesforce.com
3. 3Field Service limits (opens in a new tab)help.salesforce.com