Rules engine

Visual BPMN rules engine — turn sensor data into alarms, actions, and enrichment with safe build and rollback.

The Rules Engine is a visual automation system based on BPMN (Business Process Model and Notation) for monitoring IoT devices in real time. When sensor data meets conditions you define, the engine acts automatically — raising alarms, enriching data from other sensors before making a decision, and sending commands straight back to your devices.

That last capability changes what automation means here. A rule no longer just alerts a person to go act — it can take the action itself, the instant a condition is met. A leak sensor used to trigger an alarm and a scramble to the shutoff valve; now the same rule closes the valve automatically and raises the alarm in the same evaluation. Sense, decide, act — end to end, with no one in the loop. See Running Device Commands.

How it works

Rules are BPMN 2.0 workflows: visual flowcharts where each node performs a specific job. You connect nodes with flows (arrows) to build the logic. The engine executes a deployed rule when its Start Event receives the selected source: either a reading from one sensor or an activation from a saved trigger condition.

A rule on the visual editor canvas — a Start event flowing into a Gateway that branches into two paths ending at End events

Every rule follows a managed lifecycle:

Create → Edit → Build → Deploy → Running → Stop

Changes you make in the visual editor stay in draft until you explicitly build and deploy them. The build step validates your rule — checking the diagram structure, verifying all expressions, and confirming that every path is complete. Only after a successful build can you deploy the rule to start processing its selected sensor or trigger source.

What you can build

A rule starts with a Start Event. Choose Sensor reading to run it whenever one selected sensor reports, or Trigger condition to run it when a saved condition becomes active for one or more devices. A trigger may act immediately or wait for the condition to remain true. Each time the selected source fires, the rule executes. Inside the rule, you can:

Evaluate conditions with Exclusive Gateways — route the flow to different branches based on CEL expressions
Transform data with Script Tasks — compute derived values, classify readings, or prepare flags for downstream decisions
Fetch data from other sensors with Enrichment nodes — compare indoor vs. outdoor temperature, correlate humidity with occupancy, or check a reference reading before deciding
Raise alarms with Set Alarm nodes — trigger alarm definitions with dynamic motivation messages, kicking off escalation policies and notifications
Act on devices with Execute Command nodes — send a command (close a valve, push a setpoint, switch a relay) straight to a device when conditions are met, so the rule contains the problem instead of only reporting it. See Running Device Commands
Handle errors gracefully with Boundary Error Events — if a step fails (for example, a sensor is offline during enrichment), catch the error and route to a fallback path instead of stopping the entire rule

All conditions and computations use CEL (Common Expression Language) — a safe, sandboxed expression language designed for evaluating conditions. CEL cannot access files, make network calls, or run loops. It only evaluates expressions against the data you provide.

That balance is deliberate. Most day-to-day rules are assembled by dragging nodes onto the canvas and filling in forms. CEL appears in focused places where the rule needs exact logic: gateway conditions, Script Tasks, dynamic alarm messages, enrichment lookups, and input/output mappings. Through CEL, the rule logic can become very sophisticated — nested conditions, computed severity classifications, multi-sensor delta calculations, and dynamic decision paths that go far beyond simple threshold alerts. You are not forced into arbitrary scripts, but you are also not limited to basic "if value > X" conditions.

Safety and control

The Rules Engine is designed for environments where unmanaged automation changes are not acceptable:

Edit locks — Only one person can edit a rule at a time. Others see who holds the lock and when it expires. Organization owners can force-unlock if needed.
Autosave — Your work is saved automatically while you edit, with visible status feedback ("Saving...", "Saved", "Autosave Failed").
Version history — Every save creates a version. Versions can be renamed, viewed, and restored. If a change causes unexpected behavior, you can revert to any previous version.
Build before deploy — The build step catches structural errors, invalid expressions, and missing connections before your rule reaches production.
Artifacts — Each build produces a named artifact with timestamps, author, and optional comments. The Artifacts tab shows exactly what's deployed across all your rules.
Trash and recovery — Deleting a rule moves it to trash, not permanent deletion. You can restore rules from trash.
Emergency safety — The system monitors rule execution health and automatically stops rules that encounter sustained errors, preventing cascading failures.