Skip to main content

Notification Groups

Part of: Alerts — the reusable recipient lists that Alert Routing rules point at.

Groups live on the Notification Groups tab of the Alerts page (/alerts/groups), for users with Manage Alerts. Create one from the page's Add menu.

A notification group is a reusable, named bundle of alert recipients. Instead of typing out the same list of people into every routing rule, you build the list once as a group, and point as many rules at it as you need. Change who is in the group, and every rule that points at it picks up the change automatically.

The four member types​

A group can mix any combination of four kinds of member:

Member typePoints atReaches
UserOne specific Tagnet userThat person, while their account is active
RoleA role, such as AdminEveryone currently assigned that role
Access ScopeAn access scope, such as a siteEveryone currently assigned that scope
Email AddressA raw address with no Tagnet accountThat address, email channel only
  • A User member is a direct, personal assignment: exactly the person you picked, nobody else.
  • A Role member reaches everyone holding that role, today and going forward. Assign someone to the Admin role tomorrow, and they start hearing about alerts routed to any group with the Admin role in it, with no edit to the group required.
  • An Access Scope member reaches everyone assigned to that scope, which is useful when routing should follow a site or department rather than a fixed list of names. The person on call for a plant can change without anyone having to update the notification group.
  • An Email Address member is for a destination with no Tagnet login at all: a shared operations inbox, a distribution list, or a paging system's email gateway. Because there is no user account behind it, an email address member can only ever be reached through the Email channel; it has no in-app inbox to deliver into.

Members resolve to people at send time​

User, Role, and Access Scope members are not a frozen snapshot taken when you added them. Every time Tagnet sends a notification, it looks up who currently holds that role or scope, and who is still an active user, at that moment. An account that has since been deactivated never receives an alert, even if it was directly listed as a member.

This live resolution is also where deduplication happens: if the same person is reachable more than one way inside a group, or across two different groups that separate matching routing rules point at, Tagnet resolves everyone down to concrete user ids first and sends once per person, not once per path that reaches them.

Managing members​

A group's own Members tab, on its detail page, is where you add and remove recipients: pick a member type, then the specific user, role, scope, or email address, and click Add. The list below shows every current member with an icon for its type, a description, and a remove control. A group with no members is valid, but it silently receives nothing: any routing rule pointed at an empty group reaches nobody until you add members here.

A group's name and description are edited separately, from its Edit form, since editing who a group is and editing who it reaches are different tasks.

The Administrators group​

Tagnet seeds a system Administrators group automatically, with one member: everyone in the Admin role. It exists so the seeded catch-all routing rule (see Alert Routing) has somewhere to send critical alerts on a fresh install, before anyone has configured any routing at all.

Because it is a system group, it cannot be deleted, but its membership is fully editable: add an on-call email address, a specific person, or an access scope alongside the Admin role if you want the default protection to reach further than the Admin role alone. You can also point additional rules at it, the same as any other group.

Deleting a group​

A group still referenced by any routing rule cannot be deleted; the group list shows how many rules use it and disables the delete action until you point those rules elsewhere. System groups, including Administrators, can never be deleted, only edited.

Where to go next​

  • Alert Routing: build the rules that point at these groups, and control how often each one hears about a matching alert.
  • Alerts: back to the hub for what an alert is and how it moves through its lifecycle.