Reference · built on requestOperator by FibricFacilities & comfort

Alarm Triage

Groups building alarm floods by likely root cause and proposes one ticket per cause with the points involved.

Request accessPricing ↗

About

Alarm Triage is an operator for the alarm list in your building management platform. When a chiller trips, a field bus drops, or a schedule flips at the start of the day, one cause can raise an alarm on every point behind it. The operator reads alarms as they arrive from Metasys, Desigo CC, Niagara, or EBI, with their priority, source object, trigger value, and time, and groups the ones raised together under one likely cause.

It then proposes one ticket per cause in your work-management system, listing every point involved, and a short notice to the channel your team watches. You approve or edit each proposal. Nothing is acknowledged, discarded, or closed in the building platform unless a person chooses to do so.

This is a reference listing. It documents what Fibric would read from Alarm Triage and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Alarms from Metasys through GET /alarms, with priority, type, triggerValue, category, creationTime, and the object that raised each one
  • Events in the Desigo CC Event List, with their category and whether an operator has acknowledged or reset them
  • Alarm records from a Niagara station, their alarm class, and whether each one still needs an acknowledgement
  • Alarm and event activity surfaced through Honeywell EBI for the sites in scope
  • Open tickets in Jira Service Management, ServiceNow, or Freshservice, so a cause already ticketed is not ticketed twice
  • Schedules and the site tree, which tell it whether a burst of alarms follows an equipment start, a stop, or a lost device

Proposed actions

  • Target capability: propose one ticket per likely cause, naming the points involved and the first alarm in the burst, for your approval
  • Target capability: propose a notice to a Microsoft Teams or Slack channel that names the cause and links the proposed ticket
  • Target capability: propose acknowledging the alarms in an approved group in the building platform, where its API allows it, once per alarm
  • Target capability: propose adding later alarms from the same cause to the open ticket instead of opening a second one
  • Target capability: propose a review list of points that alarm every day and never lead to a ticket, so someone can retune or retire them

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Turn a chiller trip into one ticket

    A chiller fault raises alarms on every air handler downstream. Alarm Triage groups them under the chiller, proposes one Jira Service Management ticket listing the affected points, and posts the link to Teams.

    With Johnson Metasys, Jira Service Management, Microsoft Teams

  • Catch a lost controller before the morning

    When a field bus drops, Niagara raises communication alarms on every point behind it. The operator proposes one ServiceNow incident for the device, not one per point, and a Slack notice for the on-site technician.

    With Tridium Niagara, ServiceNow, Slack

  • Retire alarms nobody acts on

    Points that alarm in Desigo CC every night and never lead to a Freshservice ticket go on a review list. You decide which to retune, reprioritize, or remove.

    With Siemens Desigo CC, Freshservice

Requirements

  • One building management platform connector: Johnson Metasys, Siemens Desigo CC, Tridium Niagara, or Honeywell EBI
  • One work and ticket management connector such as Jira Service Management, ServiceNow, or Freshservice
  • One messaging connector such as Microsoft Teams or Slack for notices
  • A site tree or point inventory that names which equipment and which network device each alarm point belongs to
Authentication
Reads alarms through the dedicated API user or station account your building platform connector holds, and writes tickets and notices through the credentials of those connectors; it holds none of its own.

Limits

  • Grouping is by likely cause. A person confirms the cause before a ticket is filed; the operator does not diagnose the equipment.
  • It never acknowledges, discards, silences, or resets an alarm on its own, and it never touches fire or life-safety alarms.
  • Alarm history from before the operator is connected is grouped only where your platform's API serves it.
  • Each building platform exposes alarms differently. Fields such as trigger value or acknowledgement state are read only where that API provides them.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Alarm Triage ↗

Questions and answers

What does a person approve?
Each proposed ticket and notice. You see the alarms in the group, the point the operator names as the likely cause, and the ticket text. Approve it as written, edit it, or dismiss it. Acknowledging alarms in the building platform is a separate proposal you approve on its own.
What record is left?
A receipt for every proposal: the alarms grouped, the cause named, who approved it, what was written to the ticket system, and how to undo it. Dismissed proposals are kept too, so you can see which floods were judged to be noise.
Does it ever act in the building platform on its own?
No. It reads alarms, schedules, and the site tree. Any acknowledgement goes through the building platform connector as a proposal, and only where that platform's API allows it. It never writes setpoints, discards alarms, or touches fire and life-safety points.
Ask about Alarm Triage

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy