> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/ai-sre/3.0/ai-sre-for-administrators/set-up-on-call-management/manage-teams-and-notifications.md).

# Configure On-Call Teams and Routing

Harness AI SRE uses **User Groups** from the Harness Platform as the organizational unit for on-call management. User Groups serve as teams in the on-call context: they own services, own escalation policies, and determine routing for alerts.

This page covers both **administrator configuration** (User Groups, service ownership, routing) and **individual user configuration** (personal notification settings).

### User Groups as on-call teams <a href="#user-groups-as-on-call-teams" id="user-groups-as-on-call-teams"></a>

Harness AI SRE does not have a separate concept of teams. Instead, it uses **Harness User Groups** defined at the platform level.

#### What are User Groups? <a href="#what-are-user-groups" id="what-are-user-groups"></a>

User Groups are collections of users managed in the Harness Platform. They are used for:

* Role-based access control (RBAC)
* Service ownership in AI SRE
* Escalation policy ownership in AI SRE
* Alert routing in on-call management

Go to [Add and Manage User Groups](/harness-ai/use-harness-platform/platform-access-control/add-user-groups.md) to create and manage User Groups in the Harness Platform.

#### User Groups in AI SRE on-call <a href="#user-groups-in-ai-sre-on-call" id="user-groups-in-ai-sre-on-call"></a>

In the on-call context, User Groups determine:

* **Who owns which services:** Each service in the Service Directory can be assigned an owning User Group.
* **Who owns escalation policies:** Each escalation policy is owned by a User Group.
* **How alerts are routed:** Alerts for a service route to the service's owning User Group's escalation policy.

***

### Configure service ownership <a href="#configure-service-ownership" id="configure-service-ownership"></a>

Services in the AI SRE Service Directory are assigned to User Groups. This determines which team is responsible for on-call coverage when alerts fire for that service.

#### Assign a User Group to a service <a href="#assign-a-user-group-to-a-service" id="assign-a-user-group-to-a-service"></a>

Assign an owning User Group so alerts for the service route to the right team:

1. Navigate to **Project Settings** → **Service Directory (AI SRE)**.
2. Find the service you want to configure.
3. Click the service name to open its details.
4. In the **Owning User Group** field, select the User Group responsible for this service.
5. (Optional) Set an **Escalation Policy Override** if this service should use a different policy than the User Group's default.
6. Click **Save**.

#### How service ownership works <a href="#how-service-ownership-works" id="how-service-ownership-works"></a>

Service ownership drives alert routing through the following chain:

* Each service has an **owning User Group** field.
* When an alert fires for a service, AI SRE looks up the service's owning User Group.
* The alert routes to that User Group's escalation policy.
* The escalation policy determines which schedule (and therefore which on-call responder) receives the page.

***

### Escalation policy ownership <a href="#escalation-policy-ownership" id="escalation-policy-ownership"></a>

Escalation policies are owned by User Groups. This ties the policy to a specific team.

#### Policy owner field <a href="#policy-owner-field" id="policy-owner-field"></a>

When creating or editing an escalation policy:

* The **Policy Owner** field specifies which User Group owns this policy.
* This typically represents the team that uses this escalation policy for their on-call rotation.
* A User Group can have one default escalation policy, but you can create additional policies for specific scenarios.

#### Default escalation policy <a href="#default-escalation-policy" id="default-escalation-policy"></a>

The default escalation policy determines routing behavior for a User Group:

* Each User Group can have one **default escalation policy**.
* When a service's owning User Group matches an escalation policy's owner, that policy is used for routing (unless the service specifies an override).
* If a User Group has no default escalation policy, alerts for services owned by that User Group cannot be automatically routed.

***

### Alert routing flow <a href="#alert-routing-flow" id="alert-routing-flow"></a>

Alerts route through User Groups, services, and escalation policies as follows:

1. **Alert arrives** with a service identifier in the payload.
2. **Service Directory lookup:** AI SRE finds the service in the Service Directory.
3. **User Group resolution:** AI SRE identifies the service's owning User Group.
4. **Escalation policy selection:** AI SRE uses the service's escalation policy override (if configured), or the User Group's default escalation policy.
5. **Schedule lookup:** The escalation policy references one or more schedules.
6. **On-call responder identification:** AI SRE determines who is on-call at that moment.
7. **Notification dispatch:** The on-call responder's personal notification rules are triggered.

This flow ensures alerts always reach the right person based on service ownership and team structure.

***

### User notification settings <a href="#user-notification-settings" id="user-notification-settings"></a>

While administrators configure User Groups and service ownership, **each individual user** configures their own contact methods and notification rules. These personal settings determine how you are notified when you are on-call and an incident is assigned to you.

#### Contact information <a href="#contact-information" id="contact-information"></a>

Navigate to **On-Call** → **Contact Settings** to manage your notification channels.

**Available contact methods**

You can configure the following notification channels:

* **Email:** The email address tied to your Harness account. You can add additional email addresses (work, home, other) and send test notifications to verify delivery.
* **Phone:** Add phone numbers with country code selection for voice calls, and send test calls to verify delivery.
* **SMS:** Add mobile numbers for text messaging, and send test messages to verify delivery.
* **Slack:** Link your Slack account to receive direct messages. This requires the Slack workspace integration to be configured by an admin, and supports one Slack account per user.
* **Mobile app:** Install the Harness On-Call mobile app for push notifications. The app registers your device automatically when you log in. Download it from [Google Play](https://play.google.com/store/apps/details?id=com.harness.aisre\&pcampaignid=web_share) or the [App Store](https://apps.apple.com/in/app/harness-on-call/id6753579217).

Voice and SMS are supported in the following countries: United States (+1), Argentina (+54), Brazil (+55), Canada (+1), Costa Rica (+506), Cyprus (+357), Denmark (+45), India (+91), Israel (+972), Mexico (+52), Moldova (+373), Netherlands (+31), Romania (+40), Serbia (+381), Slovenia (+386), and United Kingdom (+44).

**Add a contact method**

Add and verify a notification channel from Contact Settings:

1. Navigate to **Contact Settings** in the On-Call menu.
2. Click **Add Email**, **Add Phone Number**, **Add SMS Number**, or **Add Slack**.
3. Enter the contact information.
4. For phone or SMS, select the appropriate country code.
5. Label the contact (Work, Home, Other).
6. Click **Save**.
7. Click **Test** to verify the contact method works.

#### Notification rules <a href="#notification-rules" id="notification-rules"></a>

Notification rules define the sequence and timing of how you are notified when you are on-call. Each rule contains one or more steps, and each step specifies which channels to use and how long to wait before escalating.

Go to [Configure Notification Fallback](/ai-sre/ai-sre-for-administrators/set-up-on-call-management/notification-fallback.md#notification-rule-examples) to see worked escalation sequences, create notification rule groups, understand per-channel retry behavior, and review the default notification sequence.

***

### Troubleshooting <a href="#troubleshooting" id="troubleshooting"></a>

<details>

<summary>Service alerts are not routing to the on-call responder in Harness AI SRE</summary>

Confirm the service has an owning User Group with a default escalation policy, the policy has active schedules, and the alert payload includes the correct service identifier.

</details>

<details>

<summary>An on-call user is not receiving notifications in Harness AI SRE</summary>

Verify contact methods and notification rules are configured, test each contact method, confirm the user is on-call at the time of the alert, and check the mobile app is logged in with notification permissions.

</details>

<details>

<summary>Slack notifications are not working in Harness AI SRE on-call</summary>

Confirm your organization's Slack workspace is connected to AI SRE, link your Slack account in Contact Settings, and test the connection. Only one Slack account can be linked per user.

</details>

***

### Best practices <a href="#best-practices" id="best-practices"></a>

#### For administrators <a href="#for-administrators" id="for-administrators"></a>

Follow these practices when you configure User Groups and service ownership:

* **Align User Groups with actual team structure:** User Groups should reflect real organizational teams.
* **Assign every production service to a User Group:** Unmapped services cannot route alerts automatically.
* **Ensure every User Group has a default escalation policy:** Without one, alerts cannot be routed.
* **Keep service ownership current:** Update the Service Directory when teams change ownership.
* **Document naming conventions:** Use consistent User Group names that clearly identify the team.

#### For on-call responders <a href="#for-on-call-responders" id="for-on-call-responders"></a>

Follow these practices to make sure you are reached during your on-call shift:

* **Configure at least two contact methods:** Redundancy ensures you are reached even if one channel fails.
* **Test your notification setup regularly:** Use test buttons to verify delivery before your on-call shift.
* **Keep contact information current:** Update phone numbers and email addresses immediately when they change.
* **Review your notification rules:** Ensure escalation steps match your preferred notification sequence.
* **Install the mobile app:** Push notifications are the most reliable way to receive urgent alerts.

***

### Next steps <a href="#next-steps" id="next-steps"></a>

* Go to [Configure Notification Fallback](/ai-sre/ai-sre-for-administrators/set-up-on-call-management/notification-fallback.md) to set up multi-channel notification rules and retry logic.
* Go to [Configure Escalation Policies](/ai-sre/ai-sre-for-administrators/set-up-on-call-management/define-escalation-policies.md) to configure the escalation levels that trigger notification sequences.
* Go to [Configure On-Call Schedules](/ai-sre/ai-sre-for-administrators/set-up-on-call-management/create-oncall-schedules.md) to build rotation schedules for your team.