# Alarm suppression and hierarchy

**URL:** <https://forum.inductiveautomation.com/t/alarm-suppression-and-hierarchy/3047>\
**Category:** Ignition\
**Created:** [June 28, 2011, 9:41pm UTC](https://forum.inductiveautomation.com/t/alarm-suppression-and-hierarchy/3047 "2011-06-28T21:41:46Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://forum.inductiveautomation.com/u/Robert)\
**Post date:** [June 28, 2011, 9:41pm UTC](https://forum.inductiveautomation.com/t/alarm-suppression-and-hierarchy/3047/1 "2011-06-28T21:41:46Z")

</div>

I’d like the ability to mark a device out of service. This would prevent any alarms from been generated by tags from that device.

Closely linked to this is the ability to assign parent alarms to a group of child alarms. If the parent alarm is on, none of the child alarms will be raised. When the parent alarm is reset, any child alarms in alarm will be raised.

A parent alarm could also be a child alarm.

None of this would affect the history of the associated tags.

---

<div class="post-metadata">

**Author:** ![RRNut](https://avatars.discourse-cdn.com/v4/letter/r/8e7dd6/32.png) [@RRNut](https://forum.inductiveautomation.com/u/RRNut)\
**Post date:** [June 30, 2011, 3:08am UTC](https://forum.inductiveautomation.com/t/alarm-suppression-and-hierarchy/3047/2 "2011-06-30T03:08:15Z")

</div>

I agree. This would be very benificial. This feature exists in other competive products. 😆

---

<div class="post-metadata">

**Author:** ![gnguyen](https://avatars.discourse-cdn.com/v4/letter/g/41988e/32.png) [@gnguyen](https://forum.inductiveautomation.com/u/gnguyen)\
**Post date:** [June 30, 2011, 8:39am UTC](https://forum.inductiveautomation.com/t/alarm-suppression-and-hierarchy/3047/3 "2011-06-30T08:39:08Z")

</div>

[quote]I'd like the ability to mark a device out of service. This would prevent any alarms from been generated by tags from that device.  
[/quote]  
+1 and I would add that should be possible for a single alarm too. Kind of 'inhibited' function

> [@](#):
>
> Closely linked to this is the ability to assign parent alarms to a group of child alarms. If the parent alarm is on, none of the child alarms will be raised. When the parent alarm is reset, any child alarms in alarm will be raised.

+1, yes great feature

And yes, all should be in the storage profile and each alarm get a specific status.