1. What is this module about

The Requests module is designed to facilitate the users to create requests and report issues in the building and areas they are working. For example, if an emergency light is broken or the entrance door is jamming, the user can create a request, and the responsible person or team can handle the issue. Via the request module, the request process can be monitored and evaluated.

2. High over process overview

In this chapter, a high-over overview of the process is described. For a detailed description of every step in the process, see the chapter further below: Process step by step

The Requests module has several system groups related to it, allowing authorizing users for specific parts of, and tasks within this module. Below an overview of all relevant system groups and their role within the requests workflow. Also other additional system groups without a task in the requests workflows are mentioned.

Users with the system group ‘Create requests' can create a request. From a pre defined list of problem types, the user can select the applicable problem type. The user can enter all the important information for the servicedesk team to explain the reason for creating the request and what the problem is, that needs to be solved or fixed.

After the request is submitted, the applicable servicedesk team will get the task to assign the request to a member of the servicedesk team as the user responsible for handling the request. Which servicedesk the request is assigned to, is determined by the problem type. Once the request is assigned, the servicedesk team members are able to retract the request to assign to a different responsible user or to assign the request to a different servicedesk team.

It is also possible that a request is created multiple times (by different users) for the same building, area, asset and/or problem type. Instead of assigning the request to a responsible user, the servicedesk team can mark the request as a duplicate and can select the original/initial request, where it is a duplicate from. Once the initial request is handled, all the duplicate requests will also be automatically handled.

The user responsible for handling the request can register and monitor the progress of the request. If the responsible user needs more information to be able to handle the request, the request can be forwarded to the requestor to provide more information.

Once the responsible user has handled the request, the requestor can review the request and confirm, if the problem has been solved correctly. The requestor can approve or reject the request. If the requestor does not review the request, the request will automatically close after a pre defined number of days (how many days depends on the configuration of the customer).

3. Navigation menu & Startboard

For the Requests module, the following navigation menu options become available:

For the Requests module, the following startboard tab becomes available:

This tab is available for the following system groups:

• Servicedesk employee

• Management dashboards requests

This startboard tab has some buttons similar to the navigation menu options with the same names. Next to that, this tab has the following includes (most are only visible if they contain data):

• Requests for my team, not yet assigned: This overview shows created tickets assigned to your team (service group) which have not yet been assigned to a team member to handle the request.

• Requests assigned to me: This overview shows requests assigned to me to handle.

4. Process in details

This article focuses on the key users of the requests module. More information about creating requests by end users, see: Requests for end users

4.1 Process step by step

Assign requests

When a request is created, and it is needed to assign someone to handle the request, you will see the request in your task overview on your startBoard. Click on the date to open it.

1. Check the details of the request; change or fill in missing field if needed

2. Change the service group if necessary by using the “Service group” drop down field on the right of the screen.

3. Assign the request to yourself or a colleague using the ‘Assigned to’ field. The page will refresh after selecting a person.

4. The request can now be handled.

How to handle a request

If a request is assigned to you can see it in your task list on your startBoard. Click on the hyperlink to open it.

You have different options for proceeding with the request. Please note that depending on the module settings some buttons might not be available.

• Handled
  When an issues is handled. You can click ‘Handled’. Filling in a resolution is mandatory.

• Send to Contractor
  If you can`t solve the request and a contractor is needed, use this this option and change the field “Handling by” to contractor via Email. The request will get the status ‘Contractor’ and will still editable for service desk employees.

• Need information
  Sent the request back to the requester to ask for more information

• Retract
  The status of the request will change back to “submitted” and various fields can be filled in again. For example use this if the request is assigned to the wrong service group. Don’t forget to assign the request again!

• Create work order
  Used when you can`t solve the request yourself and a work order is needed to solve this request. After creating a work order, the status of the request workflow will change to ‘Awaiting work order(s)'. It is possible to create multiple work orders. To create another work order, simply navigate back to the request. After the work order has bene handled, the status of the request will change back to ‘handle’ and you will be able to further handle the request.

Duplicate requests

It is possible to automatically determine if the request is a duplicate, this can be turn on and off in the module settings for the request module.

If a duplicate request is detected, the request will appear in your task list with text “Duplicate check request.” On opening the request, you need to check if the request is a duplicate or not.

About the proces

• After a request is submitted by a user, Workplace checks if the request is a potential duplicate.

• If the request is not a potential duplicate, the request proces continues as normal.

• However, if the request is a potential duplicate (e.g. same problem type, in the same property, for the same asset) the request gets the status 'Duplicate check'.

• The service group to whom the request is assigned now has the option to either:

  • Select a duplicate request. The status of the request now changes to ‘Duplicate’. The request now needs no further handling. Duplicate requests are automatically closed once the original request is closed. Or;

  • Determine that the request is in fact not a duplicate, the request proces continues as normal.

Options in the status 'Duplicate check'

• Choose potential duplicate
  This request is potentially a duplicate of another open request. Select "Select possible duplicate" to get a list of possible duplicates. If you recognize a duplicate, select the request and press the “Set current request as a duplicate of the chosen request.” This request will be marked as a duplicate.

• Request is not a duplicate
  If this request is not a duplicate, the request can be picked up further via the "request is not a duplicate" function.

Duplicate request checks

You can check for duplicates on different levels, the system admin can change the check duplicate settings via: Module settings > request tab.

Send to contractor (via email)

If the request is sent to a contractor via email for further handling, the service-desk employee can see this request and have a few options to proceed.

• Handle further
  For example the contractor has indicated that that request is resolved. The status off the request will change to “Handle.” The assigned person can proceed further with the request.

• Cancel the request

• Create a work order to solve the request

Creating a work order

• Created work order are linked to the request and can be found via the ‘Workorder’ tab at the bottom of the page on the request.

• Work orders can be created within a request and are used to plan, executed and monitor the work that comes from the request for contractors.

• Users who are assigned to handle a request can create a work order for that request. By default the creator of the work order will become the person internally responsible for the it.

• Work order that are created will be linked to the request and can be found in the ‘Work orders’ tab upon opening a request.

• The corrective work order manager and the other members of the service desk group responsible for the request are also able to handle the work order.

For more info about handling work orders, please view the Corrective work orders article.

Problem types

On requests you will find the field ‘Concerns’ in which the problem is selected. In the ‘Concerns’ field, so called problem types are set. These problem types are managed in a problem type scheme. The problem type scheme is configured during the implementation, but can be altered afterwards.

Managing problem types

You can create or edit problem type schemes by navigating in the menu to “Problem type schemes” under requests in the menu.

It is possible to have multiple schemes, but typically each environment will have one problem type scheme.

• To edit a problem type scheme click on the reference (or magnifying glass)

• To create a new one, press the “New” button

Changing an existing problem type scheme

Use the following instructions to add a new problems to a scheme.

After opening a problem type scheme press the button “Problem Types.”
Press the “Search” button
You can edit/add new problem types and new solution groups in this screen. add a new solution group by using the “New solutiongroup” add a new problem type by using the “New” button Click on a problem type to edit a problem type. Problem types can be classified under different parents, it will take over certain settings of the parent, like Service group.
Here you you can fill in or edit the details of a problem type. If you want to use sub requests, you will need to change the setting to yes and enter the sub requests in the include below. You have to assign a “Service group” to problem type.

The article about problem types is under construction, Problem tree, problem type scheme

Sub requests

Sub requests are requests that are automatically created after a (main) request is submitted . This functionality can be used when a certain problem type has several default actions that need to be executed. Each action will be a separate (sub) request.

For example, there is a request for a cleaning the windows on the twelfth floor (it is a building with multiple floors, 12 floors). There are several (sub) requests needed to complete the request.

1. Hire a window washer basket.

2. Hire a window washer.

3. Clean windows on the outside off the 12th floor.

4. Clean windows on the inside.

The request will be automatically closed if all sub requests are handled.

4.2 Additional options and related modules

4.3 All fields

5. Automated emails

For the request module, the following default workflow emails are available:

6. Related articles

The following articles are aimed towards application managers and implementation consultants:

For more detailed implementation information (including how to activate the module), which system groups are involved, data imports, see: Requests module activation and information

For more information on the content of this module, including detailed descriptions of some of the core components, see: Requests module in the 'Application Managers' section.