Change Management gets a lot of attention when it comes to alert suppression. Open a change, associate your CIs, alerts get suppressed. That works great — until you need suppression outside of a change. A major incident is open and your team is already working it, but the monitoring system keeps firing on the same broken thing. Or you have a planned maintenance window that doesn't warrant a formal change. Either way, nothing is suppressed and someone is getting paged.
The good news: this is solvable with standard Event Management Maintenance Rules and work that's already happening in the platform.
IMPORTANT: This approach is entirely CI-driven. If your tasks — incidents, catalog requests, etc. — don't have CIs associated to them, this won't work. Get your CI associations right first.
Using the task_ci Table
The key here is the task_ci table. It's the junction between any task record and the configuration items tied to it. When you build a Maintenance Rule that queries task_ci, you're not hard-coding CIs. You're telling Event Management: find every CI tied to tasks matching this condition and put them in maintenance.
Task lifecycle does the rest. Open task = maintenance on. Closed task = maintenance off.
Use Case 1: Major Incident Suppression
When a P1 opens, the last thing your team needs is 300 alerts confirming what they already know is broken. Build a Maintenance Rule filtered to task_ci where:
-
Task class = incident
-
Priority = 1-Critical
-
State = In Progress
Every CI tied to that incident goes into maintenance automatically. When the incident closes, maintenance ends. No one has to touch it.
Use Case 2: Catalog Item-Driven Maintenance Windows
This is my favorite pattern. Instead of a formal change, build a catalog item — a lightweight "Schedule Maintenance Window" request. The requestor fills in the CIs impacted, start date, and end date. Route it through whatever approval process makes sense. Then use Flow Designer to flip the catalog task state at the scheduled times.
Your Maintenance Rule watches task_ci for catalog tasks in state 2 (Work In Progress). Task opens → CIs go into maintenance. Task closes → maintenance ends.
NEXT: Create the Maintenance Rule
Import or create the rule directly in Event Management. Here's the XML for the catalog item version:
<em_maintenance_rule>
<name>Catalog Request Maint.</name>
<active>true</active>
<table>task_ci</table>
<ci_field>ci_item</ci_field>
<filter table="task_ci">
task.sys_class_name=sc_task^task.state=2
</filter>
</em_maintenance_rule>
Swap sc_task for incident and add your priority condition for the major incident version.
NOTE: The ci_field value ci_item is the standard field on task_ci that holds the CI reference. Don't change it.
RESULTS:
You now have dynamic, task-driven alert suppression that doesn't require a change record. The catalog item approach gives you a governed, auditable path — approvals, start/end scheduling, and automatic suppression — without anyone manually toggling a maintenance window at 2am. The major incident rule means your team works the problem without the noise.
Both patterns run on what's already in the platform. If your CIs are in order, this is about an afternoon of setup.
