4. Request Resolution and Support

The actual fulfillment of a request depends on its nature. The service desk staff may be able to fulfill a request, or the request may need to be sent to an outside group for completion.

After the request has been approved, it moves to one of the following states:

• Fulfillment, where the assigned fulfiller is responsible for overseeing the closure of the request.
• Fulfillment Queue, where the request remains until a member of the fulfillment group takes ownership of it.

In the Fulfillment state, there are different options available to the fulfiller to complete the request. The fulfiller can choose to:

• Resolve the request, completing the request and closing the issue. At this point, the fulfiller can update the Request Cost field with the actual cost. The fulfiller can enter a code in the Resolution Code field.
• Request Info, which sends the request back to the submitter to gather more information.
• Create a Task to open a subtask in the Service Request Task workflow in Service Requests. The Service Request Task workflow is a simple workflow with two main states, In Process and Closed. The request stays in the Fulfillment state while the subtask is being completed. Examples of subtasks include placing an order with a vendor and acquiring an access fob. Once the subtasks are completed, the request moves to the Task Completed state where the fulfiller can close the request. The subtasks related to the request can be seen on the Subtasks tab.
• Reassign the request to another fulfiller or move the request back into the group queue.
• Recategorize the request, moving it from this project to another.
• Create a change request from the Fulfillment state using the Create Change Request transition. Associated change requests are added to a new Linked Change Requests Multi-Relational field.
• Send the request back to the Fulfillment state using the Not Resolved transition and add an entry to the Additional Comments Journal field.

In the Fulfillment Queue state, the Assign option is used to specify the primary owner of the request.

Depending on the fulfiller's privileges, the following transitions may also be available:

• Convert to Incident creates an incident in the Incident Management application.
• Delete deletes the request.

The completed request moves to the Resolved state.