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 diagram illustrates the out-of-the-box state model for service requests. For better readability, the External processing, Information needed, and Postponed states are shown in the separate block.

States description

---

State	Description	Available transitions
Registered	A newly created service request.	Assigned Authorization In progress
Assigned	A responsible group or person is assigned.	Authorization In progress Information needed Postponed External processing
Authorization	The request must be reviewed and authorized by a responsible person or group.	Assigned Completed
In progress	The responsible person started working on the request.	Information needed Postponed External processing Completed
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.	In progress Postponed Information needed Completed
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.	Assigned In progress Postponed External processing
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.	Assigned (automatic only) In progress Information needed External processing
Completed	When a request is in the Completed state, the caller can perform testing and give feedback on the results of the implementation.	Assigned In progress Rejected by user Closed
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.	Assigned In progress Completed
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:

1. Navigate to Service Request Management → All Service Requests.
2. Open the service request you want to assign.
3. Click the magnifier icon next to the Assignment group or Assigned user field.
4. Select the responsible person or group to assign the service request.
5. 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 Assignment 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:

1. Navigate to Service Request Management → All Service Requests.
2. Open the service request you need to update.
3. Change the fields as required.
4. Click Save or Save and exit to apply the changes.

Request categories

tip

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:

1. Navigate to the Service Request Management → Request Categories.
2. Click New and fill in the fields.
3. 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

tip

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:

1. Navigate to the Service Request Management → Request Templates.
2. Click New and fill in the fields.
3. 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: New – a template has just been created. Waiting for approval – a template needs to be approved. Published – a template is published and ready to be used.
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:

1. Default (the view for those who will handle requests within the system)
2. 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.

note

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:

1. Navigate to Approvals → Approval Rules.
2. Find the rule record using the list search boxes or the condition builder and open it.
3. Select the Active checkbox.
4. 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
  1. Open the email you received and click Approve or Reject. You will be redirected to the portal page. If you reject the approval ticket.
  2. Specify the reason in the modal window and click Submit.
• via the Self-Service Portal
  1. Navigate to Cabinet → My Approvals.
  2. Open the approval ticket you need to decide on.
  3. 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
  1. Navigate to Approvals → All Approvals.
  2. Open the approval ticket you need.
  3. Click Approve or Reject at the bottom of the form.
  4. Click Save or Save and exit to apply the changes.

tip

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:

• Business Rules
• Column Types
• Client Scripts

caution

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:

1. Navigate to Portal Structure → Widgets.
2. Using the search, find the Change Request Helper in User Query widget record in the widgets list and open it.
3. Locate the condition attribute in the Template field.
4. 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: Solved 1st Level – Service agents of the 1st level solved the request without functional or hierarchical escalation. Solved 2nd Level – Service agents of the 2nd level solved the request (service agents of the 1st level were unable to solve it). Not Solved (Refused) – The caller was not satisfied with the service delivery. Not Solved (Dropped) – When the request is not a service request.
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.