# \[IGN-11371\]How to prevent "Clear" notifications when an alarm is transitioned from not enabled to enabled?

**URL:** <https://forum.inductiveautomation.com/t/ign-11371-how-to-prevent-clear-notifications-when-an-alarm-is-transitioned-from-not-enabled-to-enabled/98956>\
**Category:** Ignition\
**Tags:** ignition81, perspective\
**Created:** [November 21, 2024, 8:16pm UTC](https://forum.inductiveautomation.com/t/ign-11371-how-to-prevent-clear-notifications-when-an-alarm-is-transitioned-from-not-enabled-to-enabled/98956 "2024-11-21T20:16:08Z")\
**Posts on this page:** 7\
**Page:** 2

<div class="post-metadata">

**Author:** ![Cole\_Townsend](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/cole_townsend/32/53149_2.png) [@Cole\_Townsend](https://forum.inductiveautomation.com/u/Cole_Townsend)\
**Post date:** [April 8, 2025, 9:31pm UTC](https://forum.inductiveautomation.com/t/ign-11371-how-to-prevent-clear-notifications-when-an-alarm-is-transitioned-from-not-enabled-to-enabled/98956/21 "2025-04-08T21:31:13Z")

</div>

yeah alarm overrides are generally a nightmare since any overridden property in an alarm overrides the entire thing and keeps any changes in the UDT definition from getting rolled out. Really annoying problem by itself

---

<div class="post-metadata">

**Author:** ![tgarrison](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tgarrison/32/80965_2.png) [@tgarrison](https://forum.inductiveautomation.com/u/tgarrison)\
**Post date:** [September 18, 2025, 12:38pm UTC](https://forum.inductiveautomation.com/t/ign-11371-how-to-prevent-clear-notifications-when-an-alarm-is-transitioned-from-not-enabled-to-enabled/98956/22 "2025-09-18T12:38:30Z")

</div>

I can get away with it for the one gateway I’m having the issue with so far, as they don’t have any alarms they want Auto-Ack’d, so I’m simply using the filter extension on the journal to filter out all where ackUser = “tag:Auto-Ack”

---

<div class="post-metadata">

**Author:** ![Brad\_Beaudin](https://avatars.discourse-cdn.com/v4/letter/b/258eb7/32.png) [@Brad\_Beaudin](https://forum.inductiveautomation.com/u/Brad_Beaudin)\
**Post date:** [January 8, 2026, 9:03pm UTC](https://forum.inductiveautomation.com/t/ign-11371-how-to-prevent-clear-notifications-when-an-alarm-is-transitioned-from-not-enabled-to-enabled/98956/23 "2026-01-08T21:03:14Z")

</div>

We utilize devices that can sometimes lose connection and reconnect with alarms in an **Active State** , so it is important for us to use **Notify on Initial Events**.

Of course, this comes with a few pain points, and we ran into issues where we were flooded with **Clear** alarms, especially after a Gateway restart.

We discovered that our pipelines were set up with a **Dropout Condition**  **Acknowledged** set to **False.** As mentioned above, Cleared alarms were automatically Ack’d and thus entered the pipeline notifications.

We also had a few alarms where **Ack Mode** was set to either **Unused** or **Auto** , which was the inclination behind our dropout condition of Acknowledged being false.

2 options to help circumvent this issue.

1. Set your dropout condition for **Acknowledged** to **True** , and subsequently set your **Ack Mode** to **Manual**. Then you can choose whether or not to send an **Ack Link**. This will prevent **Clear** alarms from sending on an Initial Event.
2. If the dropout condition in your set up is require to be **False** for **Acknowledged** you can set an expression block to filter out **Initial Events** that are **Cleared.**
  1. ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/0/3/038e65106e910c1e492965f15fb1c3b6f5dd7326.png)

---

<div class="post-metadata">

**Author:** ![jrusso](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jrusso](https://forum.inductiveautomation.com/u/jrusso)\
**Post date:** [June 15, 2026, 5:57pm UTC](https://forum.inductiveautomation.com/t/ign-11371-how-to-prevent-clear-notifications-when-an-alarm-is-transitioned-from-not-enabled-to-enabled/98956/24 "2026-06-15T17:57:43Z")

</div>

Was there ever an official patch or fix for this? Running into the same issue after recently upgrading from 8.0 to 8.3

---

<div class="post-metadata">

**Author:** ![cknitter](https://avatars.discourse-cdn.com/v4/letter/c/3ec8ea/32.png) [@cknitter](https://forum.inductiveautomation.com/u/cknitter)\
**Post date:** [July 8, 2026, 1:56pm UTC](https://forum.inductiveautomation.com/t/ign-11371-how-to-prevent-clear-notifications-when-an-alarm-is-transitioned-from-not-enabled-to-enabled/98956/25 "2026-07-08T13:56:59Z")

</div>

When will this issue be resolved?

---

<div class="post-metadata">

**Author:** ![cknitter](https://avatars.discourse-cdn.com/v4/letter/c/3ec8ea/32.png) [@cknitter](https://forum.inductiveautomation.com/u/cknitter)\
**Post date:** [July 8, 2026, 1:57pm UTC](https://forum.inductiveautomation.com/t/ign-11371-how-to-prevent-clear-notifications-when-an-alarm-is-transitioned-from-not-enabled-to-enabled/98956/26 "2026-07-08T13:57:38Z")

</div>

When will this issue be resolved? Using 8.3

---

<div class="post-metadata">

**Author:** ![jrusso](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jrusso](https://forum.inductiveautomation.com/u/jrusso)\
**Post date:** [September 16, 2026, 6:44pm UTC](https://forum.inductiveautomation.com/t/ign-11371-how-to-prevent-clear-notifications-when-an-alarm-is-transitioned-from-not-enabled-to-enabled/98956/27 "2026-09-16T18:44:27Z")

</div>

A little late, but I did end up finding this checkbox in the Alarm Journal settings of 8.3.6

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/7/1729665cec12d8568469add349ab689914a03b2f.png)

[Previous page](https://forum.inductiveautomation.com/t/ign-11371-how-to-prevent-clear-notifications-when-an-alarm-is-transitioned-from-not-enabled-to-enabled/98956.md?page=1)
