IoT Integration with CMMS: From Sensor to Work Order

Everyone wants predictive maintenance. Far fewer organisations have wired the last mile that actually makes it operational: the integration that carries a sensor reading all the way into the CMMS and turns it into a scheduled, assignable, closeable work order. Without that connection you have expensive dashboards and a lot of blinking lights. With it, the maintenance system of record starts reacting to the real condition of the equipment instead of a fixed calendar. This guide walks the whole path from sensor to work order, and it is one thread in the broader story of enterprise system integration, which is where the discipline that makes these connections reliable really comes from.

The message up front: IoT integration with the CMMS is not a sensor problem or an algorithm problem. It is an integration problem. The value appears only when a condition signal crosses the boundary from the operational-technology world into the maintenance system of record and becomes a work order that a person owns, executes and closes. For the wider pattern this sits inside, start with the enterprise system integration pillar.

1. Why connect IoT to the CMMS

A CMMS on its own is a system of intent and record. It knows what maintenance you planned, what work you raised, who did it, what parts were consumed and when the next scheduled task falls due. What it does not know, unless you tell it, is the actual live condition of the equipment out in the field. Traditionally you close that gap with people: an operator notices a noise, a technician on a route records a reading, an inspection turns up a fault. Those human observations are valuable, but they are periodic, subjective and slow. A pump can develop a serious bearing fault between two monthly rounds and nobody knows until it fails.

IoT sensors close the gap continuously. A vibration sensor, a temperature probe, a current transformer or a pressure transducer streams the real condition of the asset every few minutes, every day, without a person present. On its own, though, that stream is just telemetry sitting in a historian. The reason to integrate it with the CMMS is simple: the CMMS is where maintenance work actually happens. It is where the technician sees their queue, where the planner schedules, where parts are reserved, where history accumulates and where the cost lands. If a sensor detects a developing fault but the signal never becomes a work order in that system, nothing changes. The fault still surprises you, just with more data attached.

Integrating IoT with the CMMS does three concrete things. It replaces some fixed-interval preventive work with condition-based work, so you stop servicing healthy assets on a calendar. It catches developing faults early enough to convert an emergency into a planned intervention. And it keeps the full picture, condition data plus maintenance action plus outcome, in one place, so the loop can close and the next decision is better informed. That closed loop is the whole point. Anything short of it is monitoring for its own sake.

2. From time-based to condition-based maintenance

The shift that IoT integration enables is a shift in what triggers maintenance. Under a time-based regime, the trigger is the calendar or the meter: service every 30 days, or every 500 running hours, regardless of how the asset is actually behaving. It is predictable and easy to audit, but it is blind. You over-maintain equipment that is perfectly healthy, and you can still be caught out by an asset that fails between intervals. Under a condition-based regime, the trigger is evidence: the asset itself, through its sensors, tells the CMMS when something is wrong, and only then does work get raised.

The diagram below shows the path that makes this possible. Sensors on the equipment feed an edge gateway, which aggregates and forwards data to a platform, which evaluates it against rules and models and calls the CMMS API to raise a condition-based work order when the evidence warrants it.

The important word in that diagram is only. Condition-based maintenance does not mean raising a work order every time a number moves. It means the platform holds the intelligence to decide when a reading, or a trend, genuinely warrants intervention, and only then does it reach into the CMMS. Getting that decision right is what separates a useful integration from a nuisance, and it is the subject of the honest section later in this guide. For the failure-prediction thinking that sits behind those rules and models, the predictive maintenance and failure prediction pillar goes deep on the P-F interval and remaining useful life.

3. The data that flows

Not every piece of sensor data deserves to become a work order, and not every work order needs a sensor behind it. The art of the integration is mapping specific triggers to specific CMMS actions, so the maintenance system reacts appropriately to each class of signal. The table below sets out the core use cases I build most often, each with the trigger on the sensor side and the corresponding action on the CMMS side.

Two design points sit under this table. First, each trigger produces a different class of work order: predictive, preventive, or corrective. Blurring them is a common mistake, and it makes the resulting queue impossible for planners to prioritise. Second, the meter-reading case is the one people forget, yet it is often the highest-value and lowest-risk place to start, because it does not depend on any model at all, only on carrying an accurate number across the boundary.

4. Sensor readings to work orders

The heart of the integration is the moment a reading becomes a work order. It sounds simple, but there is real design in it. A raw sensor value is not a work order. It has to pass through a decision layer that answers several questions before anything is raised: is this reading valid, or is it a sensor glitch? Is it a single spike, or a sustained trend? Does it cross a threshold that maps to a maintenance action? Has a work order already been raised for this same condition, so that we do not raise a duplicate every few minutes for the next three days?

That last question, deduplication, is where many first attempts fall over. A sensor that has breached a threshold keeps breaching it until someone fixes the asset. If the integration naively raises a work order on every breach, the technician arrives to a queue of four hundred identical work orders for the same pump. The correct pattern is stateful: the platform opens one work order when a condition is first detected, holds it open, updates it with new readings, and only closes the loop when the condition clears or the work order is completed. The CMMS should see one work order per fault event, not one per sensor sample.

When the work order is raised, the quality of what crosses the boundary matters enormously. A good condition-based work order carries the asset identifier that matches the CMMS asset register, the symptom in plain language, the sensor evidence (which reading, what value, against what limit), a suggested priority, and ideally a recommended task or inspection. A poor one carries "Asset 4471 alarm" and forces the technician to work out what it means. The integration is only as useful as the context it hands to the person who has to act. Mapping the sensor's asset identity to the CMMS asset identity cleanly, so the work order lands against the right equipment record, is unglamorous work that determines whether the whole thing is trusted.

5. Runtime and meter-based preventive maintenance

Before you reach for predictive models, there is a lower-risk, high-value integration that IoT enables: driving preventive maintenance off actual usage instead of the calendar. Most CMMS platforms already support meter-based PM, where a task falls due at a running-hours or throughput threshold rather than a fixed date. The problem has always been getting the meter reading in. Historically someone walks the plant and writes down hours meters, or the numbers are estimated, or the PM just reverts to a time schedule because the usage data is unreliable.

IoT removes that friction. If the equipment reports its running hours, energy consumed or units processed directly, the integration updates the CMMS asset meter automatically, and the meter-based PM triggers on real usage. A generator that ran hard this month gets its service sooner; one that barely ran gets it later. You stop servicing lightly-used assets too often and you stop missing service on heavily-used ones. This is condition-based maintenance in its simplest, most robust form, and it requires no machine learning, no anomaly detection, nothing but an accurate number carried reliably across the boundary.

Start here: if you are new to IoT-to-CMMS integration, begin with meter and runtime-based PM before predictive alarms. It delivers immediate, defensible value, it exercises the whole integration path end to end, and it builds organisational trust in the data feed, all without the false-alarm risk that comes with condition thresholds and models. Prove the pipe works on the easy case, then add the hard cases on top of a foundation people already believe in.

6. The integration architecture: edge, platform, CMMS API

The architecture that carries data from sensor to work order has three layers, and understanding them keeps you from being sold a black box or building a brittle one.

The edge. Sensors rarely talk to the cloud directly. They connect to an edge gateway sitting close to the equipment, which does the unglamorous but essential work of aggregating multiple sensors, buffering data when the network drops, and translating between the many industrial protocols (Modbus, BACnet, OPC UA, MQTT and their relatives) and something the platform can consume. The edge also does first-pass filtering, so that not every raw sample travels upstream. A good edge layer means the platform receives clean, normalised, well-timed data instead of a firehose of noise.

The platform. This is where telemetry is stored as time-series data and where the intelligence lives: thresholds, trend detection, anomaly models and the rules that decide when a condition warrants a work order. The platform holds the state that makes deduplication possible, and it is the component that decides whether to call the CMMS. Keeping this decision logic in the platform, rather than hard-coding it into the CMMS or into the sensors, is what lets you tune the sensitivity of the whole system without touching either end.

The CMMS API. The final hop is a call into the CMMS to create or update a work order, and this is where the integration discipline of the wider enterprise-integration world applies directly. Modern CMMS and EAM platforms expose REST APIs for work-order creation, asset lookup and meter updates. The integration must authenticate securely, map the sensor's asset identity to the CMMS asset record, create the correct work-order type with the right priority and context, handle failures gracefully (retry, queue, alert if the CMMS is unreachable), and avoid duplicates. This is precisely the same class of problem covered in the enterprise system integration pillar: two systems, an API contract, identity mapping, error handling and idempotency. The IoT dimension adds volume and real-time pressure, but the integration fundamentals are the same ones that govern CMMS-to-ERP integration and every other system-to-system link.

For the sensing and networking layer in more depth, and for how continuous monitoring behaves in a live building context, the IoT integration explained pillar and the smart building real-time monitoring pillar cover the ground below the CMMS boundary.

7. Data quality and alarm fatigue

This is the section vendors skip and the one that decides whether your program survives its first year. IoT integration with a CMMS has two failure modes that have nothing to do with the technology working, and everything to do with the data and the humans on the receiving end.

The first is data quality. Sensors drift, batteries die, mountings loosen, connectors corrode, and a sensor reporting nonsense looks exactly like a sensor reporting a fault. If a temperature probe fails and reads 5 degrees, is that a real cold reading or a dead sensor? An integration that trusts every reading uncritically will raise work orders on sensor faults, send technicians to healthy equipment, and steadily erode trust. Good integrations validate readings: range checks, rate-of-change checks, cross-checks against related sensors, and health monitoring of the sensors themselves. The maintenance program has to include maintaining the sensors, which is an overhead people rarely budget for. Poor input data does not just weaken predictions, it actively generates false work.

The honest limitation, alarm fatigue: the fastest way to kill an IoT-to-CMMS program is to raise too many work orders. Set thresholds too tight or skip the trend logic, and the system floods the queue with alerts, most of which turn out to be nothing. Within weeks the technicians learn that the sensor work orders are usually noise, and they start ignoring them, at which point the one that mattered gets ignored too. Alarm fatigue is not a minor annoyance, it is the mechanism by which good monitoring becomes worthless. Every alert must earn its place, and a quiet system that raises a small number of high-confidence, actionable work orders will always outperform a loud one that cries wolf.

The discipline that prevents alarm fatigue is deliberate restraint: use warning trends rather than instantaneous spikes, require a condition to persist before acting, tune thresholds against real history rather than vendor defaults, and review the alert-to-action ratio regularly. If most alerts do not lead to a maintenance action, the thresholds are wrong and need tightening toward relevance, not toward volume. The goal is not to detect everything, it is to detect the things worth acting on, and to keep the human on the other end trusting that a sensor work order means something. This is exactly why the failure-prediction thinking in the predictive maintenance pillar matters: knowing which failure modes have a detectable warning stops you monitoring for signals that do not exist.

8. A practical approach

Putting it together, here is the sequence I would advise any operation to follow rather than buying a platform and hunting for a use case afterwards.

• Start with meter and runtime PM. Pick a class of assets with usage meters and drive their preventive maintenance off real usage carried into the CMMS. Low risk, immediate value, and it proves the integration path end to end.
• Choose a small set of critical assets for condition monitoring. Target the rotating equipment or key infrastructure whose failure genuinely hurts and whose failure modes give a detectable warning. Do not monitor everything.
• Design the work-order mapping before the sensors arrive. Decide which trigger raises which work-order type, at what priority, with what context, and how deduplication works. The integration logic is the project, not the hardware.
• Build validation and sensor-health checks in from day one. Assume sensors will fail and readings will be wrong. Validate before you act, and monitor the sensors as assets in their own right.
• Tune for signal, not volume. Start conservative, watch the alert-to-action ratio, and tighten thresholds toward relevance. A quiet, trusted feed beats a noisy one every time.
• Close the loop and measure. Make sure the work order outcome feeds back to refine thresholds and models, and track whether unplanned downtime and reactive work actually fall. If the numbers do not move, diagnose before scaling.

Notice that the hardware is almost the last thing on this list. The integration design, the work-order mapping, the validation logic and the tuning discipline are what make the difference between a program that changes reliability and one that just adds dashboards. That is the consistent lesson across every enterprise-integration project I have delivered: the connection is where the value is created or lost, not the boxes at either end.

9. References

The following are useful, credible starting points for the standards and concepts referenced in this guide. Treat them as background reading rather than prescriptions; the right architecture always depends on your specific assets, systems and constraints.

• ISO 13374, Condition monitoring and diagnostics of machines, which defines the data-processing and information-flow blocks from sensing to advisory generation that underpin any sensor-to-work-order pipeline.
• ISO 17359, Condition monitoring and diagnostics of machines, general guidelines, for the process of selecting what to monitor based on failure modes.
• The OPC Foundation OPC UA specifications and the OASIS MQTT standard, the two protocols most commonly used to move industrial telemetry from the edge toward a platform.
• SMRP (Society for Maintenance and Reliability Professionals) best-practice metrics, for defining the reliability KPIs that prove a condition-based program is working.
• Your CMMS or EAM vendor's own API documentation for work-order creation, asset lookup and meter updates, which is the definitive reference for the final hop of the integration.

Final thoughts

IoT integration with the CMMS is the step that makes predictive and condition-based maintenance real. Sensors on their own produce telemetry; the CMMS on its own produces scheduled work from a calendar. Connect them properly and the maintenance system of record starts reacting to the actual condition of the equipment, converting emergencies into planned interventions and retiring wasteful fixed-interval work. But the value lives entirely in the quality of the connection: the identity mapping, the work-order design, the deduplication, the validation, and above all the restraint that keeps the system trusted instead of noisy.

If you take one thing from this guide, let it be the order of operations. Start with the low-risk meter-based case, prove the integration path, then add condition-based triggers on a small set of critical assets with detectable failure modes, and tune relentlessly for signal over volume. Do that and IoT-to-CMMS integration delivers exactly what predictive maintenance promises. Skip the discipline and you get the familiar story: impressive dashboards, a flood of ignored alerts, and failure rates that never moved. The technology is ready. The integration is where the work is.

Related reading: Enterprise system integration explained, IoT integration explained, Predictive maintenance and failure prediction, CMMS integration with ERP, Smart building IoT real-time monitoring.