Services on cases and portals
Services on cases and incidents
The Service field on a case
With the plugin on, a case's side column has a Service section: what the case is about. Search for the service, or pick one at the top of the list: the services the requester's account uses come first. Once it is set, the section shows the service's owner, its support team and the service level the case gets from it.
- Queue for the support team. When the service's support team works in the case's unit, one click puts the case in its queue.
- Service levels follow the service. A case that names a service with a service level (or service hours) gets that one instead of its unit's, and its due times are worked out again. Change the service's service level and its open cases follow. An offering without its own uses its service's. Clear the service and the unit's applies again.
- The timeline says who set or changed the service, or which automation did.
You see and pick only services you can see. If a case names one you can't, it says “A service you can't see”.
Finding work by service
Every work list has a Service filter while the plugin is on: the inbox, Incidents, Major incidents,
Problems, Known errors and Changes. Search for a service by name or code (retired ones too); the list
then shows the work on that service and on its offerings. In the inbox the filter also narrows the incidents,
problems and changes shown next to the cases, and a saved view keeps it. Searching the inbox
for a service's code (VPN) also finds the cases about it.
Units that need a service
A unit can ask for a service on every case: under Settings → Organization, the unit's
Services on cases card has A service before resolving. The choice covers the units below it. Whoever may
change the unit's settings (unit.settings there) may change it.
An agent then can't resolve or close the case until the service is set; the case says Needed next to Service.
[!NOTE] Requesters resolving their own case, automations, and closing after the set number of days aren't stopped.
In automations
Automations get a condition and three actions:
| Name | What it does | |
|---|---|---|
| Condition | Service | Is, is not, is, or is an offering of (a service and everything under it), is set, is not set. |
| Action | Set the service to | A service. Rules after it in the list see the service, so one rule can recognize the service from the subject and the next can route on it. |
| Action | Put in the queue of the service's support team | — |
| Action | Notify the service's owner by email | — |
For example: “When a case is created, if the subject contains VPN, set the service to VPN”, then “If the service is, or is an offering of, VPN, put it in the queue of the service's support team”.
On incidents
An incident has a Service next to its Category: the category says what kind of fault it is, the service what is affected. Declaring an incident shows the service's owner and support team, and offers to make the owner the commander. Declaring from a case brings the case's service along. The incidents list can show and filter by service.
The service's owner can choose to hear about P1 and P2 incidents on services they own: declared on the service, raised to P1 or P2, or the service named on one. It is off until they turn it on under Settings → Notifications.
The report by service
Reports → Service Configuration shows, for the period, the cases that name each service, how many were resolved, the median time to resolve and how many met their resolution target, and (with Incident Management) the incidents declared on each service and how many were P1 or P2. It counts the cases you may report on.
[!IMPORTANT] A service that cases or incidents name can't be deleted; retire it instead.
On the support portals
When accounts use your services, the portals get a Your services page: a signed-in contact sees the services their account uses now that are visible to accounts, with their status (and, for a service being retired, when). They see the description for customers in their language, never owners, teams or incidents.
The service on forms
A form, on a website or a portal, can ask which service a request is about with a Service field. By default the contact picks from the services their account uses; for an internal form it can offer any service.
Only live and retiring services that are visible to accounts are offered, of the types chosen under Settings → Service Configuration → Forms (business services, until you add technical ones).
The case gets the service before automations run, with its service level, and its form answers show the service's name.