Maintenance Alert Suppression During Planned Shutdowns

Every estate with a connected building system eventually discovers this the same way. A planned isolation goes ahead, the alarms flood in, somebody sensibly turns off the notifications so the on-call phone stops, and the work finishes. Three months later a genuine fault on the same plant produces no alarm at all, and the investigation finds a suppression that was applied for an afternoon and never lifted. Nobody did anything unreasonable at any point. The process simply had no step that made the suppression end.

The message up front: suppression must be time-bound by construction, not by discipline. Every suppression carries an expiry, expires automatically whether or not anyone remembers, is attached to the work order or permit that justified it, names an authoriser, and appears on a visible list of what is currently suppressed. Restoration is a step in closing the work, with verification that the alarms came back. If your mechanism relies on somebody remembering, it will fail, and it will fail silently in the one direction you cannot detect.

1. Four different things people call suppression

The words get used interchangeably, and because they have different risk profiles that matters.

The order of preference follows directly. Reach for notification suppression or work order gating first, use shelving where the platform supports it properly, and treat disabling at the point as a last resort requiring a higher level of authorisation and an explicit restoration task. Most of the harm in this area comes from reaching for the fourth option because it was the quickest thing available at nine on a Saturday evening.

2. Scoping it: what, exactly

A suppression that is too broad is the real hazard, because it quietly covers plant nobody intended to include.

• Scope to the asset under work, plus its known dependents. Isolating a pump will alarm the plant it serves as well as the pump itself, and suppressing only the pump leaves the storm in place. Suppressing a whole plant room to be safe is how unrelated equipment goes dark.
• Derive the dependents from the asset hierarchy rather than from memory, so the scope is reproducible and reviewable. This is one of the practical returns on a real hierarchy, as set out in asset hierarchy design.
• Scope by condition class where you can, not just by asset. During a filter change you expect differential pressure alarms; you do not expect a motor fault, and that one should still get through. Suppressing the asset entirely loses that distinction.
• Never scope by severity alone. "Suppress everything below critical on this site" is quick and indiscriminate, and sweeps in conditions on plant that is running normally.
• Record the scope explicitly, as a list of points or assets, stored with the suppression. A scope expressed as a rule that is later edited silently changes what was suppressed historically.

3. Who can authorise it, and for how long

Suppression is a control that reduces the building's ability to tell you something is wrong, so it deserves the same treatment as any other control of that kind.

• Separate who requests from who authorises, at least for anything beyond a short notification suppression. The technician on site requesting it and the duty supervisor approving it is a proportionate split.
• Scale the authorisation to the method and the duration. Notification suppression for a two-hour task is routine. Disabling an alarm at the point for a week is not, and should require someone more senior and a written reason.
• Set a maximum duration beyond which nothing can be suppressed without re-authorisation. The actual figure depends on your operation, but the existence of a ceiling is what prevents indefinite suppression, and it should be shorter than people expect to need.
• Hold the permissions in the role model rather than in individual accounts, following the approach in RBAC design for CAFM systems, so that leavers do not keep the ability.
• Require a reason from a controlled list, with free text in addition rather than instead. Reason codes make the suppression log analysable; free text alone makes it merely readable.

4. Time-bound by construction

This is the mechanism that does most of the work, and it is simple.

• Every suppression has a mandatory end time, set at creation. No open-ended option exists in the interface. If the duration is genuinely unknown, the answer is a short window that gets extended, not an indefinite one.
• Expiry is automatic. At the end time the suppression lifts itself. Expiry must not depend on a person, a ticket or a nightly job that might not run.
• Extension is an action with its own record. Extending is fine and often necessary; extending silently is not. Each extension records who, when and why, which also produces the data showing that your default window is too short.
• Warn before expiry. A notification to the requester shortly before the window closes avoids the alternative, which is the alarm storm arriving mid-task and someone suppressing it again hastily.
• Expiry restores the previous state exactly. Record what the configuration was before, so restoration is a defined operation rather than a reconstruction from memory. This matters most for the disabling case, where the pre-change state is not otherwise recoverable.

5. What must not be suppressed through this mechanism

Some alarms are not maintenance alarms and are not available to a maintenance workflow to switch off.

Fire detection and alarm, gas detection, life-safety interlocks, and anything carrying a statutory monitoring or reporting duty sit under their own regimes, with isolation governed by the standards and regulations adopted in your jurisdiction, by the authority having jurisdiction, and by the organisation's own safety management arrangements. Isolating such a system during work is a recognised activity with its own controls, its own competent persons and its own documentation. It is not the same activity as quietening a maintenance notification, and it must not be reachable from the same screen.

Practical measures that keep the boundary intact:

• Mark the out-of-scope points as a class in the data, and make the suppression function physically unable to select them. A warning is not a control.
• Identify them before the mechanism is built, with the boundary confirmed in writing by whoever holds responsibility for those systems. The usual way they get included is an export that did not distinguish the source, not a deliberate decision.
• Keep the two processes visibly separate in the interface and in the records, so that nobody can later claim ambiguity about which one they were using. The system interfaces involved are discussed in BMS integration with fire, access control and CCTV.

6. Restoration, which is where it actually fails

Applying suppression is easy and visible. Removing it is invisible, and invisible steps get skipped.

• Make restoration a mandatory step in closing the work. The job cannot be completed while a suppression raised under it remains active. This single constraint removes most of the problem.
• Verify rather than assume. Restoration means confirming the alarm configuration matches the recorded pre-change state, not just clicking "restored". For the disabling case, the verification is a test: force or simulate the condition and confirm it alarms.
• Expect a backlog of real alarms at restoration. Conditions that arose during the window will present themselves. That is correct behaviour and should be anticipated in the plan rather than treated as a fault.
• Hold a daily review of active suppressions, short, as part of normal operations. Anything on that list without a corresponding open job is an exception to chase.
• Reconcile periodically against the building system. What the suppression register believes is suppressed, and what is actually suppressed in the controls, will drift, particularly where the controls party makes changes directly. A quarterly comparison catches it.

7. The suppression log

Everything above depends on a record. The fields that make it useful rather than merely present:

That last row matters more than it looks. Suppression should mean "do not notify" and "do not raise a work order", never "do not record". Keeping the suppressed events means you can answer afterwards whether anything unexpected happened during the window, which is the question that arises when a fault is discovered shortly after planned work. The same principle governs the deduplication design in alert deduplication between BMS and CMMS, and the records join up through the trail described in the alert-to-work-order audit trail.

8. Measures worth watching

• Active suppressions right now, on a visible dashboard. If nobody can answer this in ten seconds, the mechanism is not under control.
• Suppressions without a linked work order or permit. Should be zero. Each one is an unexplained reduction in coverage.
• Suppressions ended by expiry rather than by job completion. A high proportion means people are not closing out properly, and the clock is doing work the process should be doing.
• Average and maximum duration, and extension counts. Persistent extensions mean the default window is wrong; fix the default rather than normalising the extension.
• Suppressions covering the same asset repeatedly. Often a sign the alarm configuration is wrong for the maintenance regime, and the real fix is an alarm change, not recurring suppression.
• Faults found shortly after a window closed. Worth reviewing individually. Sometimes coincidence, sometimes something that was reported during the window and nobody looked.

Where suppression for the same asset keeps recurring, the underlying issue is usually that routine maintenance predictably triggers alarms that were never designed with maintenance in mind. That is a severity and threshold question rather than a suppression question, and it belongs with the review described in alarm severity and escalation design.

The idea to walk away with

Suppression is not a feature, it is a temporary reduction in the building's ability to report problems, and it should be designed with the same care as any other temporary removal of a protection: authorised, scoped explicitly, bounded automatically, logged completely, and restored verifiably.

Almost all of the risk sits in one place, which is restoration. Build the mechanism so that it cannot depend on anybody remembering. Automatic expiry, binding to the work order, and a blocking step at job closure between them remove the failure mode entirely, and none of the three is difficult.

Final thoughts

If you have no formal mechanism today, you almost certainly have an informal one: notifications quietly turned off somewhere, alarms disabled during a project and never restored, a rule in a gateway that somebody added years ago. The first useful exercise is not building the new process but finding the existing suppressions, and the way to find them is to compare the alarms configured in the building system with the alarms that have actually fired in the last year.

Points that are configured to alarm and never have are not necessarily suppressed, but the list is short enough to walk through, and in most estates it contains a few genuine surprises.

Related reading: Alarm severity and escalation design, Alert deduplication between BMS and CMMS, The alert-to-work-order audit trail, Permit to work integration with a CMMS, Asset hierarchy design, RBAC design for CAFM systems.