Process Service Requests
State flow
The state flow of a service request is determined by the established request model. You can create your own state model and configure it accordingly using the State Flow Designer.
The following scheme illustrates an example 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.
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 request. |
|
| 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 request description is not clear enough. By setting the Information needed state, the agent requests additional information and specifies the question in the Discussion 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 Assigned. |
|
| 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 the magnifier icon next to the Assignment 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.
There is also a quick way to assign a service request to a current user. To do so, click the Start work button in the right top corner to become the Assigned user. The state of the service request changes to In progress automatically. The assigned group field remains unchanged (either with a group specified or empty). This button is available for all users who are not assigned to the service request and who have the itsm_agent role, or belong to the assigned group.
To update a service request, follow these steps:
- Navigate to Service Request Management → All Service Requests.
- Open the service request you need to update.
- Change the fields as required.
- Click Save or Save and exit to apply the changes.
Request categories
Role required: admin.
Request categories help to organize request templates into groups. It is required to create a request category before creating a request template, as the latter has to be in the parent-child relationship with some request category. You can also specify a parent category for a more in-depth categorization.
To create a request category, complete the steps below:
- Navigate to the Service Request Management → Request Categories.
- Click New and fill in the fields.
- Click Save or Save and exit to apply the changes.
Request Categories form fields
| Field | Mandatory | Description |
|---|---|---|
| Name | N | Specify a name for the category. |
| Parent category | N | Specify a category that the new category will be a child for. |
| Service catalog | N | Specify a service catalog parent for your category. |
| Description | N | Add a description for the category. |
Request templates
Role required: admin.
You can create a template that can be used later to create service requests.
To create a request template, complete the steps below:
- Navigate to the Service Request Management → Request Templates.
- Click New and fill in the fields.
- Click Save or Save and exit to apply the changes.
When the template is completed, change the State to Waiting for approval to start implementation. You can find the newly created template in the Request Template (itsm_request_template) table. You can also edit existing templates so that they meet your current needs.
Request Template form fields
| Field | Mandatory | Description |
|---|---|---|
| Name | Y | Specify a name for the template. |
| Description | N | Add a description to display on the request template card. |
| Table | Y | Specify a table containing the necessary columns for the template. |
| Create table | N | Select the checkbox to create a new table. When the checkbox is selected, the Table field becomes non-mandatory and the Parent table field appears. |
| Parent table | Y | Specify the parent table for a new one. This field appears when the Create table checkbox is selected. A new table is created when the template in the Published state. If the Parent table name is p_table, the newly created table has a name similar to the following: p_table_sc_1 |
| Service catalog | Y | Specify a service catalog where the template should be located. For service catalog configuration, navigate to Catalogs Configuration → Service Catalogs and create one that fits your needs and tasks.The service catalogs are the Service Catalogs (sc_catalogs) table records. |
| Service category | Y | Specify a service category clarifying the purpose of the template. For service category configuration, navigate to Catalogs Configuration → Service Categories and create one that fits your needs and tasks. The service categories are the Service Category (sc_category) table records. |
| Image | N | Specify an icon to display on the request template card. |
| State | N | Specify the state of the request template. Available options:
|
| Order | N | Specify the order for this request template to display on the list. |
| Active | N | Select the checkbox to activate a template and make it available for selection. |
Behavior
For the templates that have the Table field filled in, the following user interface actions will appear to create objects:
- Client Script
- Business Rule
- Column
The Table field is pre-filled with data from the Table field of the current template on the form of every new object. There are synthetic related lists on the form containing information about the columns, client-side scripts, and business rules for the table specified in the Table field.
Common features
All tables generated by templates have common characteristics:
- Title = value from the Name field
- Parent = Request
- value of the name field is generated as follows: “itsm_request_sc_” + the last number for this type of table + 1
For every table, two views are created:
- Default (the view for those who will handle requests within the system)
- Service Catalog (the view used on the Self-Service Portal)
Below is the field pool for the Default view:
- number
- requested_by
- master_it_service
- service
- related_cis
- contact_type
- state
- impact
- urgency
- priority
- assigned_user_id
- assignment_group
- subject
If the request has the State set to Authorization, the request tasks will have the state Waiting for request authorization.
Publish a request template
To publish request templates on the Self-Service Portal, you need to create a form view for the table that is specified in the Table field of the template record. Then you need to activate the template record.
If the Active checkbox is not selected, a template is inactive and cannot be used. If a request template is not active, the Service Catalog item that allows you to create service requests is not displayed on the Self-Service Portal.
The visibility of a Service Catalog item can be configured in the related Portal Node record binding the Portal record and the Service Catalog page.
Approve a request template
If necessary, the approval stage can be added to publish a template on the Self-Service Portal. The approval rule is disabled in the out-of-box solution, but it can be set up. To enable the rule, complete the following steps:
- Navigate to Approvals → Approval Rules.
- Find the rule record using the list search boxes or the condition builder and open it.
- Select the Active checkbox.
- Click Save or Save and exit to apply the changes.
You need to configure a state model for the Request Template table when the rule is enabled. A request template has to be approved by a service owner or a request manager before being configured and used.
There are three ways to approve or reject a request template:
- with email notifications
- Open the email you received and click Approve or Reject. You will be redirected to the portal page. If you reject the approval ticket.
- Specify the reason in the modal window and click Submit.
- via the Self-Service Portal
- Navigate to Cabinet → My Approvals.
- Open the approval ticket you need to decide on.
- Click Approve or Reject. If you reject the approval ticket, specify the reason in the pop-up window and click Submit.
- via the agent interface
- Navigate to Approvals → All Approvals.
- Open the approval ticket you need.
- Click Approve or Reject at the bottom of the form.
- Click Save or Save and exit to apply the changes.
Keep in mind that the only service owners specified in the Service field can decide on the approval tickets. However, any request manager can approve any request template.
Configure a request template
After a request template gets approved, a table of the same name is created and assigned to it automatically, and you need to preset columns, business rules, and client scripts that will define what the end-users will see.
As soon as the template is approved and is in the Published state, the following options appear on the template form. For more information, see the following articles:
Widget Configuration
You may need to create a request from a user query. In this case, the typical request table that was created within the template (located in the Request Template (itsm_request_template)) dictionary should be selectable in the widget modal window. To make the request table appear in the modal window, complete the steps below:
- Navigate to Portal Structure → Widgets.
- Using the search, find the Request Helper in User Query widget record in the widgets list and open it.
- Locate the condition attribute in the Template field.
- Replace the value it is delivered with (condition="nameLIKE_sc_") with the actual value for your solution. Example: condition="(sys_id=156950616617772294)^OR(parent_id=156950616617772294)^OR(nameLIKE_sc_)"
After making these changes, you will be able to choose the right table in the modal window.
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 and becomes mandatory when the service request state is Completed or Closed.
| 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. For more information, see General Concepts and Procedures. |
| Service satisfaction | N | Evaluate the quality of delivered service. For more information, see General Concepts and Procedures. |