"AI knows when your equipment will fail" is one of the better marketing lines in Salesforce Field Service. The reality is more interesting and considerably more useful: predictive maintenance in Salesforce is a four-layer pipeline — telemetry, modelling, decision, action — and most teams who say they "do predictive maintenance" are actually running step 3 and 4 with a hand-rolled threshold rule. That's often the right answer. The mistake is buying expensive ML tooling for layer 2 before the other three layers are in place.
The maintenance maturity ladder, honestly
- Reactive. It breaks; you fix it. Most operations sit here longer than they admit.
- Preventive. Calendar-based or hours-based servicing. Salesforce Maintenance Plans nail this — it's a solved problem and works without any AI.
- Condition-based / threshold. A sensor reading crosses a value; a Work Order fires. Rule-based, deterministic, fast to ship.
- Predictive. A trained model uses telemetry + historical fault data to predict failure probability. Triggers a Work Order before the threshold breaches.
- Prescriptive. Predicts the failure and recommends the action. Rare in the wild, usually combined with Agentforce.
Most organisations should aim for condition-based first. It captures most of the ROI, ships in 8–12 weeks, and gives you the data foundation predictive needs anyway. Skipping straight to predictive without that foundation is how you spend a year on a "predictive maintenance programme" with nothing in production.
The four layers — and what each one actually does
Layer 1 — Telemetry. Sensor data from the asset reaches Salesforce. Pipelines vary: MuleSoft from a SCADA historian, Kafka streams via Data Cloud, direct API calls from edge devices, or pre-aggregated integration via OSIsoft PI / Siemens MindSphere / similar. This is the layer that's most often missing. Predictive maintenance pitches assume telemetry as a given. In production we routinely meet teams whose assets aren't instrumented at all — or are instrumented but the data is trapped in a SCADA silo with no integration path. No telemetry, no prediction. Get this layer working first.
Layer 2 — Modelling. The intelligence that turns raw telemetry into a risk score. Two real options in Salesforce: Einstein Discovery (a no-code regression / classification tool that predicts a numeric outcome from a dataset — failure probability in 30 days, for instance) or Einstein Studio (BYO ML model from Databricks, AWS SageMaker, Vertex AI). For most operations, Einstein Discovery is the right fit — but it needs at least 12 months of historical fault data tied to specific Assets to train against. If you don't have that history, the model can't learn what precedes failure. Until you do, a rule-based threshold ("vibration over X for Y minutes") is functionally indistinguishable from "predictive" for most assets.
Layer 3 — Decision. The risk score (or threshold breach) becomes a triggered event. In Salesforce, this is typically a Platform Event firing a Flow or Apex trigger. Logic at this layer decides: priority, target Service Territory, target Skill, parts to pre-stage, customer notification — all standard Field Service config. This is the layer where most "AI predictive maintenance" demos actually live. The clever part isn't the prediction; it's the deterministic conversion of a score into operational action.
Layer 4 — Work Order. The Work Order is auto-created, linked to the right Asset, scheduled by the FSL Optimiser to the right Service Resource. From the customer's perspective, this is the only layer that matters: the tech showed up before the failure happened. From the architect's perspective, this layer is just standard Field Service — assuming layers 1–3 are solid.
What you need before any of this works
Salesforce demos always show layers 2–4 in their best light. The honest prerequisites — what has to be true in your org before predictive maintenance returns anything — look like this:
- Clean Asset records. Every machine in the fleet as a serialised
Assetrecord with install date, model, location, parent-child hierarchy. If your "asset register" is a spreadsheet, layer 4 has nothing to link to. - Historical fault data. 12+ months of failure events as Work Orders linked to those Assets. Einstein Discovery learns from this. No history, no useful model — just rules dressed up.
- Telemetry integration. Real-time stream from the asset to Salesforce. Without this layer, you're predicting from history alone — which is closer to "informed scheduling" than predictive.
- Field Service rollout already live. Service Territories, Resources, Skills, Maintenance Plans, the Optimiser. Predictive maintenance is the seventh thing you build, not the first.
- An action layer (Flow + Apex). The plumbing that turns a prediction into a Work Order with the right metadata. Without it, you have a dashboard, not an automation.
- Model retraining cadence. An Einstein Discovery model trained in January 2026 is useful in March. By December 2026 the underlying data has shifted. Plan quarterly retraining or your "predictive" silently degrades.
- Tolerance for false positives. No model is right 100% of the time. Pick a precision target (most teams settle around 80%) and design the workflow to absorb the rest — usually with a dispatcher review step before the auto-Work-Order fires.
Where rule-based threshold beats ML — and where it doesn't
For a meaningful subset of assets, a well-set threshold rule is just as good as an ML model. Vibration over 7.0 mm/s for more than 5 minutes → fire a Work Order doesn't need Einstein Discovery; it needs a Platform Event and a Flow. The rule is interpretable, deterministic, and survives a model retraining miss.
Where ML earns its keep is when the failure signal is multi-variate or hidden in interactions between variables. A model that learns "vibration normal AND temperature normal AND oil pressure trending downward over 3 days = failure within 14 days" can outperform any single-threshold rule because no human writes that conjunction by hand. For high-value assets with rich telemetry and rich fault history, the model wins. For everything else, a rule wins on simplicity.
The architecture-level lesson: don't default to ML because the keynote demo did. Audit your asset portfolio first. Sort by value and telemetry richness. Use rules where rules suffice, ML where ML earns its keep, and don't deploy either until layers 1, 3, 4 are working.
Where Agentforce fits
Agentforce is useful at layer 3 (decision) for explainability and exception handling — generating natural-language reasons for why an asset is flagged, alerting maintenance teams via Slack, escalating ambiguous cases to a human reviewer. It's useful at layer 4 for customer-facing communication ("we're scheduling a preventive visit on your equipment because telemetry suggests an issue developing"). What it doesn't do is replace Einstein Discovery or your threshold rules — it wraps them with reasoning and language. The same architectural pattern as dispatch applies: agent reasons, dedicated engines do the math.
Honest ROI math
Common pitch: "predictive maintenance reduces downtime by 30–50%." The honest math is closer to: condition-based + predictive together typically reduce unplanned downtime 20–40% over 12–18 months, on assets where you had decent data to start. The bigger savings often come from rationalising preventive plans — moving from "service every machine every quarter" to "service the machines that need it" — which can drop preventive visit costs 30–50% without any ML at all.
Most predictive programmes pay back through preventive optimisation more than through actual prediction. That's a useful reframe: the AI value is real, but it's not always where the slides imply it is.
Pragmatic phasing
- Foundation (months 1–3). Asset register clean. Field Service live. Maintenance Plans for calendar-based preventive work. This is the table-stakes layer.
- Threshold-based / condition (months 4–6). Pick 2–3 high-value asset types. Wire telemetry into Salesforce. Define rules. Auto-generate Work Orders on threshold breach. Most ROI lives here.
- Predictive ML (months 6–12). Pick the asset class with richest history + telemetry. Train an Einstein Discovery model. Deploy with dispatcher-review gate. Iterate on precision over 2–3 retraining cycles.
- Prescriptive + Agentforce (months 12+). Layer Agentforce for reasoning, exception handling, and customer comms. By this point you have the data foundation that makes the LLM useful.
Skipping straight to step 3 or 4 is the most common mistake. The model only works as well as steps 1 and 2 — which is to say, the model is the cherry on a cake you have to bake first.
If you're evaluating where on this maturity ladder your operation actually is — and where the next investment should land — a focused architecture review usually saves more than it costs. Book a 30-min working session if you want to talk through your specific asset and telemetry situation.