Under the Free and Essentials Plans, the tabs under the Team dashboard are limited to On-call, Integrations, Members, and Activity Stream.
Under the Free and Essentials Plans, routing can only be based upon priority or tags, and users are allowed ONLY 1 if/then rule. To configure more rules based on more fields, please upgrade to a Standard or Enterprise Plan.
Team routing rules provide the flexibility to notify a team using different escalation rules, or on-call schedules, for different alerts, at different times. It is an option to specify “No One” (simplified alert suppression), a team escalation, or a team schedule. Customize multiple routing rules, each with their own unique conditions and time intervals.
An important clarification: When routing to a schedule, it will notify only the individuals who are on-call in that schedule at the time the alert is created.
Escalations will follow the escalation policy and notify the whoever is first in the flow (users, teams, etc), then after the designated time, will notify the next, and so on until the policy is exhausted.
Routing rules can be based upon alert properties and configured to apply at specific time intervals. However, regardless of the option selected, the alert will still be visible to all team members.
When an alert is created for a team, or when the alert is assigned to a team (using the "Add Team" action), the team's routing rules will be evaluated against the alert and the appropriate schedule/escalation/no-notification will be determined: the first matching routing rule will be applied for notifying the team. In other words, only one routing rule is to be applied for an alert. Routing rules are evaluated in the (top-down) order in which they are displayed.
Click the arrow on the far right of a particular escalation to expand a quick view of the escalation policy for that team.
All teams have an escalation policy by default when the team is created. When an alert is assigned to a team, all members of the team have access to the alert and can see it in the alerts view. The team escalation policy is used to determine "who" will be notified, by default. How you can change this behavior, and notify other escalations/on-call schedules are explained above in the "Routing Rules" section.
The default configuration for the team escalation policy (as depicted above) is provided when the team is first created. Account or team admins have the right to change the configuration as needed. Find more information about Opsgenie Escalations here.
It is an option to create multiple escalation policies for the same team. When adding an escalation, designate a name, description, and rules for that escalation. Routing Rules defined on top of your Team dashboard specifies which escalation is going to be processed when an alert is assigned to the team.
All teams have an on-call schedule by default when the team is created. To leverage scheduling capabilities, an escalation policy step should point to the team schedule. First step of the default team escalation policy points to the on-call schedule user.
The default schedule configuration includes the team members that are added when the team is created in a weekly rotation. Admins can modify the schedules as needed.
Further actions can be taken with schedules for easy access and sharing by hovering over the schedule section of a team's dashboard and accessing these icons (pictured below):
- Copy Calendar Link
- Open Calendar
- Export team schedule
Define multiple schedules for the same team. By selecting "Notify on-call user(s) in schedule" in Routing Rules on top of a Team's dashboard, directly specify a schedule to be used when the team is assigned to an alert.
A rotation is a group of people who alternate through the same shift. Multiple rotations are optional for the schedule as rotations can be restricted to specified time periods. When an alert escalates to the schedule, all on-call users in all the different rotations are notified (cumulative).
Opsgenie provides ad-hoc schedule exceptions, allowing schedule modifications without altering your schedule (rotations) settings. Overrides can be defined by admins or team members. A team member can take the on-call responsibility for the time interval he/she specifies. Team admins can define overrides for other members of the team as well. A schedule override replaces all on-call users from different rotations of the schedule.
There are multiple ways to assign a team to an alert: via the web UI, the REST API, or more commonly, via integrations. An individual alert can also be assigned to multiple teams. When an alert is assigned to a team, the team's routing rules are evaluated against the alert to to determine which mechanism (escalation policies, schedules) should be used:
For a team escalation, its rules are run to notify the alert recipients.
For a team schedule, its current on-call users are notified for the alert.
Opsgenie also provides an optional alert field called "recipients" to specify who should be notified for that alert. If the recipients field is used when an alert is getting created, recipients field supersedes the teams assignment. The team members would still have access to the alerts (can see the alerts and execute actions), but the recipients field will be used to determine who should be notified. The recipients field can be used to specify different users, groups, schedules or escalations, instead of the team escalation policy. For existing alerts, add recipients and add teams actions can be used to notify other users that may not be members of the team.
Also see Alert Recipients & Teams for details about alert's visibility and recipients.
- Any alert created via integrations that are assigned to a particular team are routed to the team that this integration is assigned to. In other words, a team restricted integration can not have any recipient or any team other than the assigned team to route the alert. Please note: that when an alert is routed to a team, routing rules of the team are used to determine which escalation or schedule should be used while adding recipient users to the alert to send notifications.
- Team restricted integrations can execute an alert action only if the alert is visible to the team that the integration is assigned to. Similarly, a team restricted API integration can only access the alerts that are visible to the assigned team, regardless of whether the retrieving request is Get Alert or List Alerts.
- Team restricted integrations can access alert recipients, notes or logs only if the alert is visible to the assigned team.
- A team restricted API integration can only access the following API domains with the following restrictions:
-Heartbeat API: Heartbeat should be restricted to the same team with the API key.
-Teams API: Team should be the owner of integration.
-Escalations API : Escalation should be restricted to the same team with the API key.
-Schedules API: Schedule should be restricted to the same team with the API key.
-Schedule Overrides API: Schedule should be restricted to the same team with the API key.
-Integration API (Deprecated): Target integration should be restricted to the same team with the API key.
- An outgoing team-restricted integration can not send callbacks for an alert that is not visible to the team that the integrations is assigned to.
Default API integrations can not be assigned to any team.
Teams can configure their own heartbeats and heartbeat integrations to streamline a heartbeat monitoring flow that is specific to their teams. When a team heartbeat is expired, an alert will be created using the heartbeat integration of the same team. Please note: a team API key can not be used to ping the global heartbeats or the heartbeats of other teams.
To create a Service, access the Services sub-menu on the Team’s Dashboard and click Add Service. Here is where you would also see the list of defined Services with their descriptions and visibility.
You define a Service by entering (and saving) Service Name, Service Description , and visibility (private to your Team or visible to the organization).
For more information on Services, see Services.