Skip to content
Contact us
  • There are no suggestions because the search field is empty.

Groups — Overview (Concepts and Core Components)

Overview

Purpose: Explain AlertOps’ philosophy of Groups as the core unit for who gets notified and the key components that make a Group work (members, roles, schedules, contact methods, topics, and nesting).

Audience: AlertOps Owner, App Admin, Group Admin, and anyone responsible for on-call structure.

Prerequisites:

  1. Entitlements:

  • Groups_Add_GlobalAccess: Create Groups

  • Groups_Update_GlobalAccess: Update and Delete all Groups

  • Groups_Update_GroupAccess: Update and Delete Groups of which individual user is already a member

  • Groups_View_GlobalAccess: View All Groups within the Environment.

  • Groups_View_GroupAccess: View Groups and members for groups they are in.

  2. Roles:

  • Owner

  • App Admin

  • Group Admin

  • Integrations Admin (Groups_View_GlobalAccess entitlement)

  3. Articles:

Getting Started

Users, Permissions and Roles

Outcomes: Knowledge of:

  • What a Group represents in AlertOps

  • How membership and roles influence escalation

  • How schedules/shifts, contact methods, and topics relate to Groups

Guidde Video

00:00: This article explains how to create an edit groups within the alertops platform.

00:06: You will learn the steps to add a new group and update its details.

00:10: Begin by accessing the Alertops dashboard, where you can manage your groups and schedules.

00:17: Click on the 'Groups and Schedules' section to continue.

00:21: Click the add group button to start creating a new group within the platform.

00:27: Enter the name of the group, such as 'Platform Support', to identify the group's purpose.

00:33: Click the submit button to save the new group and add it to your list of groups.

00:39: Click the 'EDIT' option next to the group you want to modify to update its details.

00:45: Click in the description field to add or change the group's description for clarity.

00:50: Click the done button, to save your changes and finalize, the group editing process.

 

Feature Explanation

Why Groups exist

Groups are designed to answer two operational questions consistently:

Who should be notified?

When should they be notified?

A Group is typically a team (e.g., “SRE On-Call”), but can also represent a function, region, tier (L1/L2), or a blended rotation.

What a Group contains (core components)

A Group brings together these building blocks:

1) Members (Users and nested Groups)

You can add Users to a Group.

You can also add a Group to another Group (nested groups) to model multi-team escalations or tiered support structures.

2) Member types (Standard vs Stakeholder)

Standard users: can take response actions (e.g., Assignment, Escalation, replying to alerts).

Stakeholder users: receive notifications but cannot take response actions.

3) Member roles (Primary, Secondary, Manager)

Groups support three role tiers that influence escalation intent:

Primary: First tier in the escalation sequence (first responder on call)

Secondary: Second tier in the escalation sequence (backup responder)

Manager: Used for manager escalation paths in case both primary and secondary fail to respond to alerts in due time; can also be Primary or Secondary

Manager role capabilities

A user assigned the Manager role can edit anything within the Group they manage, including:

User details

Schedules

Out of Office

Note: You can set Primary and Secondary roles from the Group member list when you create the Group and before attaching a Schedule to it, as there exists a lone 24x7 shift by default. The moment you add another Shift under the Schedule and configure Shift specific Primary, Secondary and Rotating roles, the toggle columns of Primary and Secondary roles from the Group Member list get removed.

4) Schedules and shifts (when the Group is “active”)

Schedules define when specific users are the expected responders.

Groups can contain multiple shifts (fixed or rotating)

Shifts can have overrides

The Group schedule can be viewed in timeline or calendar format (toggle on the right side of the schedule screen)

5) Contact methods (how the Group can be reached)

Groups can store shared/team contact endpoints, viz.:

Group Email and SMS

Primary and Secondary Email

Primary and Secondary Phone

6) Topics (fast manual routing + pre-templated messages)

A Topic can be associated to a Group for quick, consistent communication, especially for Manual Alerting.

Note: A Topic must already exist (be configured beforehand) before you can add it to a Group.

How it works (high-level)

At runtime, workflows and routing logic target Groups to:

choose which responders are eligible (membership + role)

choose which responders are on duty (schedule/shifts)

apply escalation intent (Primary → Secondary → Manager, based on configured sequence and workflows)

Tip: Keep Groups stable (structure + naming) and treat schedules/shifts as the mechanism that changes over time.

Best Practices

Do:

  • Treat Groups as stable “teams/tiers” and use schedules to represent changing rotations.

  • Keep a clean tier design (Primary vs Secondary vs Manager) and document your escalation intent.

  • Use nested groups for layered support models (L1 → L2) when it simplifies operations.

  • Pre-configure Topics for common incident scenarios used in manual alerting.

Don’t:

  • Overload a single Group with unrelated teams; it makes escalation hard to reason about.

Related Articles

Groups — Operations (Create, Update, Delete, Members, Roles, Schedules, Contact Methods, Topics)

Groups — Bulk Operations (Import/Export Groups and Group Members via Spreadsheet)