Request Management: Generic Service Request

The Generic Service Request process provides a basic Service Request process that is suitable for extending to suit your exact requirements. The process diagram is shown in three sections below, then described in more detail later.

There are six parts to the Generic Service Request process, which are in the order:

  1. Creation
  2. Authorization
  3. Stock Check
  4. Provisioning
  5. Request Fulfilled
  6. Unsubscribe

These are described in more detail below.

Creation Sequence

If a requested CI has not been selected (for example, if an end user has logged a General Request), the process is assigned to the Service Desk group and moves to the Awaiting Response status; otherwise it moves to the Is Parent A Bundle? decision. At the Awaiting Response status you can use the Assign to Me action to assign the request to the current user, and you can add a note. The Add Note action adds the note and also notifies the users that the analyst selects on the Note window (end users cannot choose to notify additional users); the current assigned user is also always notified, unless that is the Raise User.

The Assign to Me and Add Note features described above are used again throughout this process.

From the Awaiting Response status, the Complete Mandatory Data action is followed by a decision, which tests the value of the Is Parent A Bundle attribute on the Request object. By default, in Object Designer, this attribute is set to False, which therefore passes the process into the Authorization Sequence. This attribute, however, is set to True for Child Requests created by the Bundle Request process (see Request Management: Bundle Request). When Is Parent A Bundle is set to True, the process bypasses the Authorization Sequence, as the request has already been authorized by the parent Bundle Request process.

Authorization Sequence

The Authorization Sequence is replicated in other processes.

Four authorizations are possible, depending on values set on the window for the Service selected in the Request:

At each of these stages the assignee can Authorize or Reject the Request. If the Request is rejected, the Request is closed with the status of Rejected; if it is authorized by all of the required authorizers, the Request progresses to the Stock Check stage.

Stock Check Sequence

The Stock Check Sequence enables you to confirm that there is a license or some stock in place for the requested service.

If the Requires Stock or License? check box on the Service window is NOT selected, the process bypasses the Stock Check Sequence. Otherwise, it is assigned to the Stock Check Group and Stock Check User that are set on the window for the requested CI. You can add further steps to the Stock Check Sequence to meet your specific requirements.

At this stage, the Request can be canceled, which closes the Request with the status of Canceled, or the stock can be identified, which passes the Request into the Provisioning Sequence. As an interim stage, the item can be identified as unavailable, which moves the process to the status Out of Stock. You could write a query to identify Requests at this status to help you to expedite the provision of items that are out of stock.

Provisioning Sequence

When the Request has been authorized and, if necessary, the stock has been checked, it is assigned to the group selected in the Fulfillment Group list on the Service window.

The Provisioning Sequence includes a placeholder where you can include some process automation, such as integration with Ivanti Process Manager (LPM).

Request Fulfilled

If the service that has been provided is a Request Once service, an automatic action links the requested item with the Raise User.

If the Requires Customer Confirmation? check box is selected on the Service window for the requested service, the Request is assigned to the Raise User to confirm that they have received the service.

If the Service IS NOT a Request Once service, the Request moves to the End Status Closed. If the Service IS a Request Once service, the Request moves to the Completed Status of Subscribed.

Unsubscribe Sequence

If an end-user requests a Request Once service, the process reaches a completed status of Subscribed. The end-user can then use the Unsubscribe action to withdraw the service. The Request is then assigned to the SA user. You need to change this. We recommend that you assign the Request to a group or a role.

When the Service has been removed from the user, the link between the User and the CI is automatically broken, and the Request is closed.

Optional actions for each status:

Status

Optional actions

Open

None

Awaiting Response

Add Assignment
Add Attachment

Awaiting Authorization

Add Attachment

Awaiting Service Authorization

Add Attachment

Awaiting IT Authorization

Add Attachment

Awaiting Business Authorization

Add Attachment

Checking Stock Availability

Add Assignment
Add Attachment
Add Task

Out of Stock

Add Assignment
Add Attachment
Add Task

Provisioning

Add Assignment
Add Attachment
Add Task

User Confirmation

Add Attachment
Add Note

Subscribed

None

To Withdraw

Add Assignment
Add Attachment
Add Task

Closed

None

Canceled

None

Rejected

None


Was this article useful?    

The topic was:

Inaccurate

Incomplete

Not what I expected

Other