The most common failure mode for predictive maintenance programs is not technical. The detection works, the alerts are accurate, but the information does not fit into the workflow that determines what gets dispatched, when, and with what priority. Alerts that exist only in a separate monitoring dashboard, disconnected from the SCADA screens operators watch all day and the CMMS work orders that translate alerts into field crew actions, tend to get reviewed sporadically and acted on late or not at all.
I have had direct conversations with utility distribution engineers about this. The pattern is consistent: a monitoring system produces an alert, the alert is visible in the monitoring system's own interface, and then the information sits there while the maintenance team continues to work from their CMMS queue, which has no awareness of the monitoring alert. By the time the alert is reviewed, either the situation has resolved on its own or it has progressed to the point where it is visible in other ways.
This article covers the integration architecture that makes predictive maintenance alerts operationally effective: how monitoring data connects to SCADA, how alerts translate into CMMS work orders, and where the workflow boundaries are that make the difference between an alert that gets acted on and one that gets reviewed after the fact.
SCADA Integration: OPC-UA as the Common Language
Modern SCADA systems in utility operations use OPC-UA (OPC Unified Architecture) as the standard protocol for integrating real-time measurement data from field devices and monitoring systems. OPC-UA provides a vendor-neutral, secure data exchange framework with hierarchical node addressing, publish-subscribe event notifications, and historical data access.
For a monitoring system like Magnefy to integrate with an operator's SCADA, the standard path is to expose monitoring data and alerts as OPC-UA nodes on the Magnefy data server, which the operator's SCADA system can then subscribe to and display on existing operator screens. This does not require changes to the SCADA configuration for the transformer's primary electrical measurements. It adds a secondary data source that appears alongside the existing measurements.
The practical configuration involves defining the OPC-UA node structure for each monitored transformer, which typically includes the current asset health score, the active alert status and severity, the key signal deviation values that triggered any active alert, and the alert timestamp and alert ID for correlation with CMMS records. The SCADA operator can then configure displays that show the monitoring status alongside the transformer's electrical measurements, so that an active monitoring alert is visible in the same context as the load and temperature readings for that transformer.
OPC-UA integration requires network access between the monitoring system and the SCADA network, which touches utility IT/OT boundary policies. In utility environments, the OT network containing SCADA is typically isolated from the corporate IT network and from external connections. The integration architecture needs to account for this boundary: monitoring data from Magnefy's cloud processing needs to reach the operator's SCADA through a path that complies with the utility's OT security architecture, which typically involves a data diode or secure gateway in the DMZ between the corporate and OT networks.
Alert-to-Work-Order: The CMMS Webhook Path
SCADA integration puts monitoring status in front of operators, but it does not create the work orders that drive field crew dispatch. That is the CMMS's domain. The path from a monitoring alert to a CMMS work order is the critical operational link, and without it, the alert requires a human to notice it in SCADA, decide it warrants a work order, and manually enter that work order into the CMMS.
The standard modern integration path is a webhook: when a monitoring alert triggers, the monitoring system sends an HTTP POST to a configured webhook endpoint in the CMMS, with a payload containing the alert details. Most enterprise CMMS platforms support inbound webhooks with configurable work order creation rules: a received webhook payload that matches the defined schema triggers the creation of a work order with the appropriate asset ID, work type, priority, and description populated from the webhook payload.
For transformer monitoring alerts, the webhook payload should include the transformer asset ID (mapped to the CMMS asset record), the alert type (which corresponds to a specific work type in the CMMS, such as "transformer diagnostic investigation"), the priority level derived from the alert severity, the monitoring system's internal alert ID for correlation, and a summary of the alert rationale suitable for the work order description field. The work order created by the webhook becomes visible to the planning team immediately, queued alongside all other pending work, with the correct asset, work type, and priority already populated.
The webhook approach requires the monitoring system and CMMS to be aligned on asset identifiers. If the transformer is identified by a feeder designation in the monitoring system and by a different equipment tag in the CMMS, the webhook payload needs to carry the CMMS asset tag, not the monitoring system's internal identifier. Setting up this mapping correctly during onboarding is a configuration step that requires input from both the monitoring vendor and the CMMS administrator.
REST API for Historical Data and Reporting Integration
Beyond real-time alerts, there is operational value in being able to query monitoring history directly from other systems. The primary use cases are: CMMS work order closure review (when a work order is closed after an inspection, what did the monitoring data show before and after the inspection?), asset health reporting in the utility's enterprise asset management system, and capital planning analysis that correlates monitoring findings with the decision to replace or continue operating aging transformers.
A REST API on the monitoring system's data platform provides access to these historical queries. The API design for utility operations needs to support time-range queries on a per-asset basis, returning the health score history, alert history with timestamps and alert IDs, and the underlying signal deviation history that drove health score changes. For capital planning use cases, a fleet-level endpoint that returns current health scores and trend direction across all monitored assets is more useful than per-asset queries.
Integrating monitoring data into enterprise asset management reporting through the REST API does not require tight SCADA integration. An engineer can pull asset health history through the API, correlate it with maintenance records from the CMMS, and produce a capital investment priority ranking that combines age, operating history, inspection findings, and monitoring health score trajectory. This is a less automated integration than real-time alert routing, but it can be implemented without touching the OT network boundary and without CMMS webhook configuration.
Workflow Design: Matching Alerts to Response Protocols
The integration architecture determines how monitoring information reaches operators and planners. The workflow design determines what they do with it. These are separate problems, and the technical integration does not solve the workflow problem.
Effective alert response requires defining in advance what each alert severity level means for dispatch decisions. A low-severity EM anomaly, where the health score deviation is outside normal range but has not triggered the high-priority threshold, should map to a specific response: increase the DGA sampling frequency, schedule a visual inspection at the next available opportunity, and continue monitoring. A high-severity alert should map to a different response: request an expedited DGA sample within a defined timeframe, restrict the transformer's operating load, and prepare a contingency switching plan.
Without this pre-definition, each alert becomes an ad-hoc decision. The dispatcher receives a CMMS work order with priority "urgent" and a description that references a monitoring alert, but has no procedure that says what "urgent" means in the context of a monitoring-generated work order versus a trouble call or a relay operation. The result is that monitoring-generated work orders get treated with the same priority logic as any other work order, which may not reflect the time sensitivity of the monitoring finding.
We do not write these response protocols for operators. They know their systems, their crew resources, and their switching capabilities better than we do. What we do is provide the alert severity classification, the underlying signal data, and the alert type classification that allows an operator to map the alert into their existing response framework. The integration carries that information; the workflow design uses it.
What Integration Does Not Solve
One thing I want to be direct about: tight SCADA and CMMS integration does not improve the underlying quality of the monitoring signal. If the EM anomaly detection is producing false positives on a particular transformer due to a persistent noise source in that substation environment, routing those false positives automatically into CMMS work orders creates work for field crews, not value. Integration amplifies the monitoring system's performance, in both directions.
The right sequence is: validate the monitoring performance on the actual transformer population before enabling automatic work order creation. A trial period where alerts are visible in the monitoring system but do not automatically generate CMMS work orders allows the operations team to evaluate alert quality and calibrate their response posture. After the monitoring has demonstrated alert quality that meets the team's threshold for operational use, the automatic CMMS integration can be enabled with confidence that the work orders it generates represent genuine actionable findings.
That validation period also identifies the calibration needs for individual transformers. Some transformers in any fleet will require threshold adjustments or additional baseline data before the monitoring alert quality is high enough to drive automatic dispatch. That is expected and should be planned for. Integration is the final step in a commissioning sequence, not the first.