Skip to main content
Version: 1.10.1

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


StateDescriptionAvailable transitions
RegisteredA newly created service request.
  • Assigned
  • Authorization
  • In progress
AssignedA responsible group or person is assigned.
  • Authorization
  • In progress
  • Information needed
  • Postponed
  • External processing
AuthorizationThe request must be reviewed and authorized by a responsible person or group.
  • Assigned
  • Completed
In progressThe responsible person started working on the request.
  • Information needed
  • Postponed
  • External processing
  • Completed
External processingSolving 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
  • External processing
Information neededThe 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
PostponedThe 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
  • Information needed
  • External processing
CompletedWhen 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 userIf 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
ClosedThe 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 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:

  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

FieldMandatoryDescription
NameNSpecify a name for the category.
Parent categoryNSpecify a category that the new category will be a child for.
Service catalogNSpecify a service catalog parent for your category.
DescriptionNAdd 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

FieldMandatoryDescription
NameYSpecify a name for the template.
DescriptionNAdd a description to display on the request template card.
TableYSpecify a table containing the necessary columns for the template.
Create tableNSelect 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 tableYSpecify 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 catalogYSpecify 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 categoryYSpecify 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.
ImageNSpecify an icon to display on the request template card.
StateNSpecify 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.
OrderNSpecify the order for this request template to display on the list.
ActiveNSelect 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:

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 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.

FieldMandatoryDescription
Closure notesYSpecify some notes summarizing the implementation process.
Closure codeYSpecify 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 satisfactionNEvaluate the agent performance. For more information, see General Concepts and Procedures.
Service satisfactionNEvaluate the quality of delivered service. For more information, see General Concepts and Procedures.