View Source

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.

Click the image to open it in full screen mode.

SimpleOne Documentation (Official) > Process Service Requests > request_state_flow_en.png

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
Information needed
Postponed
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
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:

Navigate to Service Request Management → All Service Requests.
Open the service request you want to assign.
Click 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.

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. Generally, 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. Generally, 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:

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

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:

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	Add a summary of the implementation process.
Closure code	Y	Specify a closure code: Solved 1st Level – service agents of the 1^st level solved the request without functional or hierarchical escalation. Solved 2nd Level – service agents of the 2^nd level solved the request (service agents of the 1^st 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.