CMMS Integration with IoT: Making Maintenance Actually Use the Data

The most expensive failure mode of an industrial IoT project: alerts that arrive in a system maintenance teams don’t use. Telemetry detects a bearing wearing out; an email goes to a SCADA dashboard nobody opens; the bearing fails a week later. The CMMS — IBM Maximo, SAP PM, eMaint, UpKeep, Fiix — is where work happens. IoT integration that doesn’t end there isn’t really integration.

What good integration looks like

When a predictive-maintenance signal fires, three things should happen automatically:

1. A work order is created in the CMMS, with the relevant asset, location, and recommended action
2. The work order carries the diagnostic context — the metric that crossed threshold, the trend chart, the recommended part numbers
3. When the technician completes the work, the outcome is fed back to the IoT side, so the model improves

If the integration only does step 1, the work order arrives without context and gets deprioritised. If it only does steps 1-2, the loop is open and the IoT model never improves. Get all three.

The CMMS landscape in 2026

The dominant CMMS / EAM systems we see on engagements:

• IBM Maximo Application Suite — enterprise heavyweight, common in oil & gas, utilities, large manufacturing. Modern API surface; older deployments may be on legacy versions.
• SAP Plant Maintenance (PM) — for SAP-aligned customers, integrated with SAP ECC or S/4HANA. Reaches deep into procurement and finance.
• Oracle EAM / Maintenance Cloud — Oracle-aligned customers, common in utilities.
• Infor EAM — common in manufacturing and public sector.
• Mid-market: eMaint, Fiix, UpKeep, Limble — SaaS-first, modern APIs, popular with smaller manufacturers.
• Hippo CMMS, Maintenance Connection — smaller, often single-site deployments.

Each has different integration ergonomics. The mid-market SaaS options have the cleanest APIs in 2026; the enterprise ones have the deepest data models.

Integration patterns

Pattern A — Webhook into the CMMS API

The simplest pattern when the CMMS has a modern REST API.

• IoT side detects an actionable event
• A small dispatcher service translates the event into a CMMS work order via the CMMS’s REST API
• Idempotency keys prevent duplicate work orders on retry
• Failure goes to a dead-letter queue with alerting

Suits: eMaint, Fiix, UpKeep, modern Maximo deployments. Most CMMS APIs are reasonable in 2026.

For broader webhook patterns see our webhooks vs streaming post.

Pattern B — Middleware / iPaaS

For enterprise CMMS with complex business logic, an integration platform (MuleSoft, Boomi, Azure Logic Apps, AWS EventBridge) sits between IoT and CMMS.

The middleware:

• Subscribes to the IoT event stream
• Applies business rules (which alerts become work orders, which get paged, which get logged)
• Calls the CMMS API with proper field mapping
• Handles authentication, rate limiting, retries

When the CMMS is SAP PM or legacy Maximo, middleware is almost always the right call. Skipping it means writing the business rules in custom code that gets harder to change every quarter.

Pattern C — File-based or batch

For older CMMS deployments without API surface or with restrictive change control, a file-drop or batch import is often the realistic option.

The IoT side writes a file (CSV, XML) to a shared location. A scheduled job in the CMMS imports the file and creates work orders. Latency is hours, not seconds.

This is a stopgap, not a destination. But for a customer with a 15-year-old Maximo deployment, it gets the integration shipping while a longer-term modernisation runs in parallel.

The work-order content matters

A work order auto-generated from IoT data needs context. Without it, the technician arriving at the asset has no idea what they’re looking for.

What to include:

• Asset reference — exact equipment ID matching the CMMS asset register
• Symptom — “Bearing temperature trending up over 14 days, currently at 78°C, normal range 50-65°C”
• Diagnostic chart — link or embed a 30-day trend of the relevant metric
• Recommended action — “Inspect bearing, check lubrication, schedule replacement if grease degraded”
• Recommended parts — part numbers from the asset’s BOM, ideally with stock-level info
• Severity — auto-assigned based on the predicted time-to-failure
• Linked alerts — if multiple metrics fired, all in one work order, not many

The richer the work order, the more likely the technician trusts it. Trust is the operational currency that decides whether the integration works.

Closing the feedback loop

Pattern A or B handles the outbound side. The inbound side is rarer and more valuable.

When a technician completes the work order in the CMMS, the system should:

1. Capture the finding — what was actually wrong (could differ from what the model predicted)
2. Capture the action — what was actually done
3. Capture the outcome — did the symptom resolve

This data flows back to the IoT side via webhook, polling, or batch:

• The IoT model is retrained or recalibrated based on real findings
• False-positive rates per detection rule are tracked
• Pareto charts of “predicted vs actual” failures inform model improvement

A CMMS-to-IoT feedback loop is what separates predictive-maintenance projects that improve over time from those that plateau.

Common pitfalls

1. Asset ID mismatch. The IoT side knows asset 0xA712; the CMMS knows asset PUMP-04-NORTH. Without a mapping, work orders go to wrong assets or get rejected. Maintain an explicit asset master that both sides reference.

2. Alert flooding. A single sensor going noisy can generate hundreds of work orders. Rate-limit at the dispatcher; deduplicate within a window; require minimum confidence levels before creating work orders.

3. No human review path. Sometimes the model is wrong. The integration needs a path for “this is a false positive” that closes the work order without action and feeds back to the model.

4. CMMS field mismatches. Fields you assumed are free text are required-and-validated. Fields you assumed take the symptom text are limited to 80 characters. Profile the target CMMS API thoroughly before designing the dispatcher.

What we typically deliver

For a CMMS-IoT integration engagement:

• Asset master mapping between IoT and CMMS identifiers, version-controlled
• Dispatcher service translating IoT events to work orders, idempotent and rate-limited
• Field mapping document for the target CMMS, validated against real API responses
• Closing-loop integration for technician findings flowing back to the IoT side
• Operational dashboards tracking integration health (work orders created, dispatched, completed, false-positive rates)
• Runbook for when the integration fails, including manual fallback procedures

If you are integrating IoT alerts into a CMMS — and the technicians aren’t yet acting on them — we have shipped this combination across enterprise customers.