You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 14 Next »
The following scheme illustrates the default state model for service requests. For better readability, the transitions available after the In Progress state are shown in a separate scheme on the right.
Click the image to open it in full screen mode.
You can create your own state model and configure it in the preferred way using the State Flow Designer.
States description
State | Description | Available Transitions |
---|---|---|
Registered | A newly created service request. |
|
Assigned | A responsible group or person is assigned. |
|
Authorization | The request must be reviewed and authorized by a responsible person or group. |
|
In Progress | The responsible person started working on the issue. |
|
External Processing | Solving the request requires the participation of a third party. When the third-party participation is over, the request state and the assigned user should be changed to the previous ones. |
|
Information Needed | The issue description is not clear enough. By setting the Information Needed state, the agent requests additional information and specifies the question in the Additional Comments field. After the user answers via email, the request state automatically changes to Assigned. |
|
Postponed | The Postponed state means that solving the request should be postponed for a known period. The date and time are specified in the Resumption of work field. On the date and time defined in the Resumption of work field, the state will be In Progress. |
|
Completed | When a request is in the Completed state, the caller can perform testing and give feedback on the results of the implementation. |
|
Rejected by User | If the caller is not satisfied with the results of the agent's work, they can reject it. The state will change to Rejected by User. |
|
Closed | The request is Closed when the caller accepts the results, or a specific period of time has passed. This period can be specified in the itsm.itsm_request.days_count_to_solution_accept property. Once the Closed state is set, the request cannot be reopened. |
Assign and update service requests
To assign a service request, follow these steps:
- Navigate to Service Request Management → All Service Requests.
- Open the service request you want to assign.
- Click on the magnifier icon
next to the Assigned Group or Assigned User field.
- Select the responsible person or group to assign the service request.
- Click Save or Save and Exit to apply the changes.
To update a service request, follow these steps:
- Navigate to Service Request Management → All Service Requests.
- Open the service request you want to update.
- Change the fields as requires.
- Click Save or Save and Exit to apply the changes.
Service request authorization
vv
Closure information
Based on the state model, the service request has to be closed when it has been fully processed. The Closure Information tab appears when the service request state is Completed.
Field | Mandatory | Description |
Closure Notes | Y | Specify some notes summarizing the implementation process. |
Closure Code | Y | Specify a closure code:
|
Agent Satisfaction | N | Evaluate the agent performance. Available options:
|
Service Satisfaction | N | Evaluate the quality of delivered service. Available options:
|
The values of Agent Satisfaction and Service Satisfaction fields are connected with the values of the choice options that appear on the Self-Service Portal:
- Below Expectations = Disappointed
- Meets Expectations = Satisfied
- Above Expectations = Very Pleased
- No labels