How to Connect Building Automation Systems (BAS) to a CMMS

Your building automation system already knows when something is wrong. A chiller pulling too much amperage, an AHU running hot, a fire panel throwing a fault at 2 a.m., the BAS sees all of it in real time. The problem is what happens next. In most facilities, that alarm sits on an operator workstation until someone happens to notice it, decides it’s worth acting on, and manually types up a work order in a completely separate system.

BAS CMMS integration closes that gap. When you connect BMS to CMMS, building performance data flows directly into your maintenance workflow, so alarms become prioritized work orders in minutes instead of hours. This guide walks through why that connection matters, the protocols and architectures involved, and a step-by-step process for setting it up.

Why BAS and CMMS Need to Work Together

A building automation system and a CMMS are built to do different jobs. The BAS monitors and controls HVAC, lighting, fire systems, and other mechanical equipment, collecting thousands of data points an hour. The CMMS manages the human side of maintenance: work orders, technician assignments, parts, and history.

Left disconnected, the handoff between “something is wrong” and “someone is fixing it” depends entirely on a person noticing the alarm and manually creating a ticket. That gap is where facilities teams lose the most time. Industry research on facilities operations consistently points to reactive maintenance eating up a large share of a maintenance team’s week, much of which could be avoided if building data triggered maintenance action automatically.

The Protocols Behind a BAS-CMMS Connection

Before you connect BMS to CMMS, it helps to know which language your building speaks. Three protocols cover the vast majority of buildings:

BACnet. Developed by ASHRAE and published as an ANSI standard, BACnet is the closest thing building automation has to a universal language. It’s object-oriented, meaning every data point (a temperature sensor, an alarm, a schedule) is a defined object with standard properties, which makes it straightforward for a CMMS to interpret. BACnet also has native alarm and event notification, so your CMMS can subscribe to specific alarm types instead of constantly polling for changes.

Modbus. Older and simpler than BACnet, Modbus is still common on standalone equipment like boilers, chillers, and submeters. It’s register-based, so your integration needs a register map, and it has no built-in alarming; your integration layer has to poll and compare values against thresholds itself.

LonWorks. A peer-to-peer protocol popular in older and European buildings, LonWorks usually needs a dedicated gateway to translate into BACnet or a web API before a modern CMMS can use it.

Three Ways to Connect BMS to CMMS

There isn’t one universal path for BAS CMMS integration. The right approach depends on your BAS age, protocol, and how many buildings you’re managing.

1. API-based integration. Your BAS head-end (Niagara, Honeywell EBI, Siemens Desigo CC, Johnson Controls Metasys, and similar platforms) exposes data through a REST API, and your CMMS consumes it directly. This is usually the fastest and cheapest route for a modern, single-vendor BAS, and it works well with cloud-based CMMS platforms since it typically only needs outbound HTTPS.

2. Middleware. For portfolios running multiple BAS vendors across different sites, a middleware layer (Niagara, SkySpark, CopperTree, or a custom pipeline) sits between the BAS systems and the CMMS, translating and normalizing everything into one feed. It handles complexity well but adds another platform to license and maintain.

3. Direct or IoT-native integration. Some CMMS platforms speak BAS protocols natively, or use lightweight edge gateways, so alarm data flows straight into the same system that manages work orders and assets. Fewer moving parts, lower latency, but it depends on your CMMS having that native capability.

What Automated Work Order Generation Looks Like

This is the core use case that makes BAS CMMS integration worth the effort. Here’s the typical flow:

1. The BAS detects a fault, for example an AHU supply air temperature exceeding setpoint for a sustained period.
2. The alarm is sent to the CMMS through an API webhook or direct integration.
3. The CMMS auto-creates a work order with the asset ID, location, alarm details, and recent trend data.
4. The system assigns priority and routes the ticket to the right technician based on skills and availability.
5. The technician gets a mobile notification and responds, often with the relevant history already attached.

Facilities teams that put this in place typically see alarm-to-response time drop from hours to minutes, along with fewer emergency callouts, because problems get caught before they escalate.

Other High-Value Use Cases

• Runtime-based preventive maintenance. Instead of servicing an AHU every 90 days regardless of how hard it’s been running, the CMMS triggers PM work orders based on actual accumulated runtime hours pulled from the BAS.

• Energy anomaly detection. When equipment consumption drifts from its baseline, the CMMS opens an investigation ticket instead of the waste going unnoticed for weeks.
• Comfort complaint correlation. A tenant complaint about a stuffy room can automatically pull current zone temperature and damper position from the BAS, so the technician knows what they’re walking into before they arrive.
• Compliance reporting. Operational data from the BAS and maintenance records from the CMMS combine into one report instead of two separate manual exports.

Step-by-Step: Connecting Your BAS to a CMMS

1. Audit your BAS. Document the vendor, protocol (BACnet, Modbus, LonWorks, or proprietary), network setup, and how many alarms you’re currently generating.
2. Decide what data actually belongs in the CMMS. Fault alarms and runtime hours should flow through in real time or daily; setpoints and schedules usually don’t need to leave the BAS at all.
3. Choose your architecture. API-based for a modern single-vendor BAS, middleware for a multi-vendor portfolio, direct integration if your CMMS supports it natively.
4. Map alarms to work orders. Decide which alarm severities map to which work order priorities, which equipment maps to which CMMS asset, and how you’ll prevent one flapping alarm from generating fifty duplicate tickets.
5. Test before going live. Simulate alarms, confirm routing and notifications work, and check that runtime data is accumulating correctly.
6. Tune after launch. Expect to adjust alarm thresholds in the first few weeks; BAS alarms tuned for a human operator are often too sensitive for automatic work order creation.

Common Integration Challenges

• Alarm flooding. Route only confirmed fault conditions, not every advisory alert, and add a short time delay so transient issues that self-resolve don’t generate tickets.
• Network segmentation. BAS systems often sit on an isolated operational technology network. A secure edge gateway with outbound-only data flow is usually enough to satisfy IT security without opening the network up.
• Inconsistent asset naming. If the BAS calls something “AHU-3F-01” and the CMMS calls it “Air Handler, 3rd Floor East,” nothing will match. A standardized naming convention mapped early on saves a lot of rework later.
• Legacy protocols. Protocol gateways (BACnet-to-Modbus, for example) are inexpensive and mature enough to bridge most older systems without a full controller replacement.

Frequently Asked Questions

What’s the difference between a BAS and a BMS? The terms are largely used interchangeably in the industry; both refer to the centralized system that monitors and controls a building’s HVAC, lighting, and related equipment.

How long does BAS CMMS integration take? Anywhere from three to fourteen weeks depending on the architecture, with API-based and direct integrations generally landing on the faster end.

Can an older BAS still connect to a modern CMMS? In most cases, yes. Protocol gateways and middleware exist specifically to bridge legacy BAS protocols with modern, cloud-based CMMS platforms.

What data should actually be sent to the CMMS? Prioritize fault alarms, runtime hours, and energy anomalies. Leave setpoints, schedules, and routine control data in the BAS unless there’s a specific reporting need.

Bringing BAS Data Into FacilityBot

FacilityBot is a cloud-based CMMS software built to turn building automation alarms into action, not just another log entry. Its fault reporting software connects directly with BAS-generated alerts and converts them into prioritized, assigned work orders in real time, so problems get routed to the right technician before they turn into a bigger repair bill. As maintenance management software, FacilityBot goes beyond basic ticketing: it centralizes asset history, preventive maintenance scheduling, and inventory in one platform, giving facilities teams a single source of truth instead of juggling the BAS workstation and a separate CMMS. For teams evaluating CMMS software with BAS integration as a requirement, FacilityBot is built to make that connection straightforward rather than an afterthought.