Request Sub-statuses

Home > Service Manager > Service Portfolio > Service Details > Services Request Configuration > Request Sub-statuses

Introduction The Request Sub-statuses lets you define a number of descriptive states of a request that are related to the request being either Active or On-hold. Using the Sub-status can help control the situations under which a request is put On-hold or made Active again. An example of an On-hold Sub-status might be With Customer which when selected could place the request's status to On-hold and stop any allocated Service Level Target timers.

Related Articles Services Request Configuration Global Request Sub-statuses Business Process - Set Sub-status Request Settings

Request Sub-status Options

The Management of the Request Sub-statuses is done from within the Service Form

• Sub-status Name

The Name of the sub-status is what will be displayed to an analyst from within a request

• Alternative Customer Label

An alternative Label can be provided which will be visible to the customer from within the Customer or Service Portals. This is only applicable to request types that are accessible on the Portals.

• Request Type

A sub-status can be made available to All requests types or you can select from one of the available request types on which this particular Sub-status will be available.

• Parent Status

The selection of a sub-status controls if the request is placed in either an Active or On-hold state when the sub-status is selected. A Sub-status that is set with a Parent Status of Active will either keep the request in an active state (New, Open, Resolved) or if the request is On-hold the state will change back to its Active state. A Sub-status that is set with a Parent Status of On-hold will either change the status of the the request to On-hold if it is currently in an active state (New, Open, Resolve) or it will maintain an On-hold state if it already on-hold.

• Reason Required

This setting is used to enforce an entry by the user that is putting the request on-hold for this particular sub-state

• Pause Until Date / Time

If choosing the Parent Status of On-Hold, this option will allow you to determine if the analyst moving the request into a specific sub-status will be prompted to put it on-hold until a defined date and time, after which it will automatically come off-hold, or if you choose No the analyst will not be prompted to set an on-hold until date and time, and instead the request will remain on-hold until it is manually taken off-hold. If choosing this option the analyst will be presented with the option to set a reminder activity when placing the request into this on-hold status.

When creating your sub-statuses it is important that at least one Active sub-status exists to allow you to move from an On-hold state to an Active state.

Use Request Settings to control which actions on a request are enabled when a request is on hold

• Language

If you support more than one language in your environment you can provide the appropriate translations for these languages

• Status - Only Sub-statuses set to Published will be visible to use in Service Manager.

• Draft - Can be used to create Sub-statuses but not be visible
• Retired - Once Published, a Sub-status can be moved into a retired status if no longer required

• Auto-Update - Toggle this option On If you wish to allow customer updates (Portal or Email) to a request whilst in this Sub-Status, to automatically change the Sub-status, to the Sub-Status defined in the On Customer Update change the Sub-Status to... dropdown, on the Service and Request Type of the Request.

The Sub-status which a customer update will change to, can be configured per service and per request type on the Service views in Service Manager, making this granular per Service and Request Type

The toggle option for Auto-Update will be greyed out if viewing Globally defined Sub-Statuses from the Service View. These Globally defined Sub-Statuses can be managed through the Admin Console > Service Manager > Configuration

On Customer Response Change Sub-Status to...

Sub-statuses can often be used for scenarios where a request has been put on hold as some feedback or an update is required by the customer before proceeding. The On Customer Response options allows the sub-status to automatically change to the selected sub-status when the customer performs one of the following actions on the request in the Self Service Portals or when an email update is received on a request

Self Service Actions

• Adds a comment to a post
• Adds a post (update)
• Adds an attachment
• Confirms a resolution has worked
• Confirms a resolution hasn't worked

Email Actions

• Manually applied emails to a Request
• Emails Automatically added to a Request via Routing Rules

By Default both Manual and Routing Rule based email updates will constitute a customer update, this can be changed if required through the following system settings:

• app.email.allowRequestSubStatusUpdates - Allow automated Sub-status updates on requests when applying an update from email
• app.email.routing.rules.allowRequestSubStatusUpdates - Allow automated Sub-status updates on requests from auto responder updates

On Auto Off-hold Change Sub-Status to...

When a request is place on hold by a support person an option can be enabled for each On-hold sub-status that prompts the support person to enter a date and time for the request to become active again. When a sub-status has been set in the On Auto Off-hold field, the sub-status will automatically change to the the selected sub-status when the request comes off-hold.

If a request is in an On-hold state at the time it is resolved, the request will automatically be taken off hold. The sub-status set within this configuration will then be applied to the request.