Incident management

Four things are easy to confuse here, and getting them straight saves a lot of time:

• Alarm configuration — defines what counts as a problem.
  

• Alert configuration — defines who gets told about it, and how.
  

• Alert groups — reusable sets of recipients.
  

• Incident handling — where you actually work through the deviations that result.
  

Alarm configuration

An alarm watches a value and decides when it has gone wrong. Beyond a simple threshold, alarms can compare a base value against a comparison value: the alarm triggers only when the difference between them exceeds the difference you set, and stays there for longer than the response delay. The response delay is what keeps a brief transient from becoming an alarm — a supply temperature that dips for thirty seconds during a start-up is not a fault.

Creating a temperature alarm for a meeting room.

BACnet alarms

Not every alarm is one you wrote. Where a building's automation system already has alarms of its own, Properate can read them and present them as deviations alongside the ones you configured. That saves rebuilding rules that already exist in the automation central.

Viewing BACnet alarms.

Alert configuration and alert groups

An alert configuration decides what happens when an alarm triggers: which alarms it covers, and who is notified by email or SMS. Recipients can be gathered into alert groups so you do not maintain the same list of names in a dozen places. SMS goes to the phone number on each user's profile.

Create the group before the configuration. An alert configuration asks who should be notified, so with a group already in place you select it in one step instead of adding names one by one — and the same group can then serve every alarm setup that follows.

Create an alert group

Creating an alert group for a building. The walkthrough shows the Norwegian interface.

Create an alert configuration

Setting up a new alert rule for indoor climate.

Notification throttling

When the same alarm triggers repeatedly in a short space of time, the extra notifications are collected into a single summary rather than sent individually. Other alarms in the same notification setup are delivered as normal, so a single flapping sensor cannot bury a genuine second fault.

This is on by default in every notification setup and can be switched off where you do not want it.

In practice: someone on weekend duty gets one message that a sensor is flapping, instead of an alert for every spike through the night.

Illustration of the feature — not a screenshot from the app.

Incident handling

Incident handling is the working list. Search it, filter by severity, and see what is unassigned — unassigned items are the ones most likely to be quietly forgotten. Open an incident to see details and the underlying deviations. At organisation level, the same view spans every building in the portfolio, and you can filter between all alarms and just your own.

Incident handling. Filters on severity, source and status narrow a long list quickly.

One incident in detail: the base value over time, the alarm configuration behind it, and who it is assigned to.

Review an incident

Opening an incident gives you three things: the detail of what triggered it, the historical activity behind it, and somewhere to record what you made of it. That last part is what carries forward — an acknowledgement says somebody saw the alarm, a comment says whether the plant is at fault or a door stood open all afternoon.

Reviewing an incident: the detail, the historical activity, and adding a comment.

Good to know

• If a building uses BACnet alarms, enabling them synchronises with the BACnet central and can take a few minutes before the configurations appear.
  

• An alarm with no alert configuration still records deviations — it just will not tell anyone. Worth checking if incidents are appearing but nobody is hearing about them.