Refine your service desk setup

The Setup page gets one team, one SLA target per priority, and three notification rules running. This guide goes past those defaults: a second team, a clock that behaves differently for one priority, an offering with an SLA of its own, and exactly which rule tells whom. For the ideas behind routing and the SLA clock, read Service Hub and SLA first.

Goal

Add a second team, hand it its own request type with its own SLA, adjust one priority’s clock, and confirm who each notification rule reaches.

Prerequisites

The platform.iam.write capability, to create a group and add its members.
The platform.servicedef.write capability, to create a Service Offering or edit an SLA template.
The platform.notifications.write capability, to edit a notification rule.

Steps

1. Add a second team

Go to Admin → Access & Governance → Groups (/admin/iam/groups) and create a group for the new team. Open it and use Add Member to add its people. This group is independent of the one Setup created; nothing you do here changes your first team.

2. Give it an offering with its own SLA

Go to Admin → Service Delivery → Service Offerings (/services/offerings) and create a new offering. Set Technical owner team (routed assignment group) to the group you just created, and set SLA template to the SLA you want it to carry.

An offering’s own SLA template always wins: a request routed through this offering is held to that SLA regardless of its priority. Leave SLA template unset instead, and the request falls back to your tenant’s default SLA for its priority, the same as your first offering. If neither applies, the request carries no clock, and says so.

Bind a catalog item to the new offering the way Service Hub describes, so a request actually reaches it.

3. Give one priority its own clock

Setup created one SLA per priority, named after the priority and its targets, for example “High (P2): 30m response / 8h resolve”. On the same Service Offerings page, open the SLA templates tab, click that row, and adjust its Response Time (minutes), Resolution Time (minutes), or its Business Calendar. Setting a Business Calendar makes that priority’s clock run only during business hours; clearing it makes the clock run around the clock, the same choice Setup makes for Critical and High by default.

4. Decide which rule tells whom

Go to Admin → Automate → Notifications (/admin/notifications). Setup left three rules running: caller on public comment, caller on resolve, and group on create. Open one to change its Recipient Type: Specific Users, Users by Role, Users by Group, or a value read from the record itself, such as the caller. Point group on create at your new team’s group instead of, or alongside, your first team’s, so the right people hear about a new request the moment it lands.

A priority change on a record already in flight does not move its due dates. The clock a record is stamped with when it is created governs it until it closes.

Verification

You know it worked when:

A request routed through your new offering carries its own SLA due dates, not the tenant default.
The priority you adjusted in step 3 keeps to its new response and resolution minutes, and runs on or off business hours as you set it.
A request that reaches your new offering notifies your new team, not just your first one.

Troubleshooting

Symptom	Cause	Fix
A request still gets the tenant’s default SLA, not the one you set	The offering’s SLA template field is empty	Open the offering and set SLA template to the SLA you want it to carry
The new team never hears about a request	The offering’s routed assignment group still names the old team, or no notification rule points at the new group	Check Technical owner team (routed assignment group) on the offering, and add the new group as a recipient on the create rule
A record’s due dates did not change after you edited its priority	Priority changes never re-stamp an existing record’s clock	This is expected; the new targets apply to requests created after the change

Service Hub: how a catalog item and an offering route a request.
SLA: how the clock runs, pauses, and breaches.
Notifications: trigger events, recipients, and delivery.