[This article is currently being revised, see down below for old part]

1. Requests in general

‪A request system is a tool used to report and address issues or maintenance needs within a facility or office building. The person creating a request provides detailed and essential information about the issue, so that the responsible person or team can handle the issue accordingly and within the specified period. The request process give transparency to the requestor and to the responsible about the progress of the request.

Overall, a request system in facility management streamlines the process of reporting and resolving issues, leading to improved efficiency, better communication, and enhanced facility maintenance. It helps ensure that the facility remains safe, functional, and comfortable for its occupants.

2. 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 repsonsible person or team can handle the issue. Via the request module, the request process can be monitored and evaluated.

2.1 Service groups

Service groups are the most important components of the requests module. A service group is usually a group of users responsible for handling the submitted requests. Small companies might only have one service group handling all requests and bigger companies can have multiple service groups for each of the departments.

For example, the service group ‘IT’ handles all IT related requests, the service group ‘Facility' handles all building and area related requests and the service group 'Landscaping’ handles all requests related to the environment outside and around the building.

Service groups are automatically determined in a request based on the selected problemtype (more about problemtypes in the next chapter). The request is automatically assigned to the entire service group and one of the members of that service group can assign the request to him or herself as the responsible person to handle the request.

2.2 Problemtypes

Another very important element of the requests module are the problemtypes. A problemtype is a way to distinguish between different types of requests. A user creating a request can select the problemtype from a pre defined drop-down lists. All the problemtypes which can be selected in a request and the hierarchy of the problemtypes is determined by the customer.

Option 1: The customer only wants two problemtypes which can be selected in a request:

1. Cleaning request

2. IT request

Option 2: The customer has a problemtype list with a hierarchy with different levels. The user creating the request first selects the top level and then the next level of problemtypes become available to select based on the previous level:

1. Cleaning

   1. Toilets

   2. Kitchen

2. IT

   1. Request a new device

   2. Device stolen or missing

   3. Issues with device

      1. Laptop

      2. Phone

      3. Tablet

3. Electricity

   1. Defect wall outlet

   2. Defect light

4. Furniture

   1. …

   2. …

In this case, first the user needs to select the main problemtype (Cleaning, IT, Electricity or Furniture). After selecting for example 'Electricity', the sub problemtypes becomes available and the user needs to select the next applicable problemtype (Defect wall outlet or Defect light).

The customer can add as many main and sub level problemtypes, but needs to keep the user experience in mind, when creating a request. 5 or 6 levels in the problemtype hierarchy means the user creating the request needs to make a lot of choices and might not be aware what the difference is between several problemtypes.

For the user creating the request, the problemtype is an easy way to describe the issue or problem. The problemtype is not only used to have a pre defined list of possible problemtypes the user (creating the request) can choose from, but the problemtype also has a lot of settings which can influence the handling process. Some important settings on problemtypes:

• Service group: To which service group is the request automatically assigned to.

• Priority: The priority determined in the problemtype is automatically taken over to the request.

• Additonal information and picture: More information specified in the problemtype is automatically displayed in the request to help the user either solving the problem or describe the issue correctly.

• Mandatory and visible fields: The problemtype determines if certain fields (buidling, area and asset) are mandatory to fill in, not mandatory or not even visible).

• Work order settings: In the problemtype several work order settings can also apply, but more on this in the corrective work order chapter.

2.3 Service Level Agreement (SLA)

SLAs or Service Level Agreements can be used to determine within which period the request must be responded to and within which period the request must be resolved. The priority of the request (determined by the problemtype) is used to determine the response time and handle time of the request.

For example:

• The response time for a 'High' priority request is 2 hours and the handle time is 1 business day after the request was submitted

• The response time for a 'Low' priority request is 1 week and the handle time is 1 month after the request was submitted

Via the module settings 'Requests', the SLA times can be enabled and can be managed per priority for both the response time and the handle time.

For each workflow task it can be determined, if the time spend while the workflow task was active, needs to be taken into account for the response time and/or the handle time.

For example:

• The request is still in draft and not yet submitted by the user → the response time is not yet started

• The request is submitted, but not yet assigned to the responsible user → the response time is started

• The request is assigned back to the requestor, because the request is not clear → the response time is pauzed

• The request is (re)submitted and not yet assigned to the responsible user → the response time is started

• The request is assiged to the responsbible user → the response time is stopped, the handle time is started

• The request is handled and the requestor is informed → the handle time is stopped

After the request is closed, the response time and handle time can be evaluated, via several default reports on the requests dashboard, based on the SLA times applicable and proper actions can be taken based on the available data.

2.4 Corrective work orders

Corrective work orders can be used as an extension for requests. A corrective work order is always created as a result of a request. Corrective work order can not be created without a request. As the word 'corrective' already suggests, something needs to be corrected or fixed.

Corrective work orders can be enabled in general via the module settings 'Requests'. In this case, for every request, corrective work orders can be created. Creating corrective work orders can also be depending on the problemtype. For some problemtypes it might be not applicable to create work orders and for other problemtypes it might be applicable.

More information about corrective work order module can be found: Corrective workorders module activation and information

2.5 Other relevant options

2.5.1 Sub requests

If a problemtype consists of multiple actions for multiple service groups, sub requests can be used. With sub requests, the main request is automatically broken down into one or more sub requests. After the main request is submitted, it moves to a 'Waiting for sub requests' status. The sub requests are all assigned to the applicable service group. Once all sub requests have been handled, the main request is automatically closed.

For example, if a new employee is hired, a request is created to prepare a new work laptop. The problemtype 'New employee laptop' consists of several sub requests:

• Purchase a new laptop → service group 'Purchasing'

• Create a new mailbox for the employee → service group 'IT'

• Prepare the laptop with all relevant software → service group 'IT'

• Distribute the laptop on the first day → service group 'Office Manager'

2.5.2 Duplicate check

Automatic duplicate checks can be enabled, when a request is submitted. If a problem occured in the main hall, where all employees pass by, it could be that more than one user creates a request with the same problemtype, same building and same area. Instead of the service group receiving for example 10 requests about the same issue, only one request is assigned to the service gorup and the other 9 requests are marked as a duplicate of the first request. Once the first request is handled, all the duplicates are also handled automatically.

Duplicate check can be enabled for:

• The same problemtype

• The same building

• The same area

• The same asset

The duplicate check is only executed for open requests. Already closed requests with the same problemtype, the same building and the same area for example, are not taken into account.

2.5.3 Preferred suppliers

With preferred suppliers, requests or work orders can automatically be assigned to the preferred supplier based on the role specified in the problemtype. Preferred suppliers can be applicable in general, per building, per area or per asset. A preferred supplier is a combination of a role and a supplier.

For example:

• Supplier A - Role: IT

• Supplier B - Role: Landscaping

• Supplier C - Role: Furniture

If a request is submitted with the problemtype role 'IT', the application checks ifthere are preferred suppliers:

1. If an asset is linked to the request → check on preferred suppliers for that asset with the role 'IT'

2. If an area is linked to the request → check on preferred suppliers for that area with the role 'IT'

3. If a building is linked to the request → check on preferred suppliers for that building with the role 'IT'

4. Check on preferred suppliers in general with the role 'IT'

If a preferred supplier is found, it will be automatically linked as the contractor to a possible corrective work order being created for this request.

2.5.4 Simple ticketing via the Workplace App

Via the Workplace (Experience) App it is also possible to create a request. A pre defined problemtype with service group is set up in Workplace Management and the created request from the Workplace App will be automatically assigned to the pre defined problemtype and corresponding service group to be handled.

3. Why use this module

This module enables employees/users to easily submit work-related requests or report problems. The system automatically assigns these requests to the appropriate team for resolution, eliminating the need for users to find the right person or team themselves. Additionally, the module allows requests to be divided into one or more corrective work orders, which can be sent to preferred suppliers automatically. Users can track the progress of their requests through reports and dashboards, evaluating if requests have been handled within the set SLA times and and work orders completed by suppliers.

3.1 Choices to be made within the module

The most relevant choices that can be made when using this module are the following:

1. Which service groups are used by the customer? All service group members will be users of the Workplace Management application and will get tasks to handle requests.

2. Which problemtypes are applicable for the customer? Does the customer want a simple list with only a couple of problemtypes to choose from or a complete hierarchy of problemtypes with multiple levels?

3. Does the customer want to use corrective work orders? Requests can be handled directly by the responsible service group (member) or via corrective work orders created from the request, which can be assigned to internal users or external suppliers to register relevant costs and handle the problem. If the customer wants to use corrective work orders:

   1. Use corrective work orders in general: corrective work orders can be created in all requests (independent from problemtype)

   2. Use corrective work orders based on the problemtype: Determine per problemtype if corrective work orders can be created.

4. Are SLAs used to monitor the response and handle times of requests? If so, register the desired response and handle times per priority.

4. How to activate this module

As for every new module, use the ‘Module activation’ option on the administrator startboard (only available for level 2 and level 3 admins). For more general information about these 'Module activation' options, see Module activation

4.1 Prerequisites before enabling this module

The requests module does not require any other modules to be activated before. However, if you want to be able to link a specific building, area and/or asset to a request, these modules will need to be activated first. Otherwise, it is only possible to register the specific building, area and/or asset in a description field. Insights about the number of requests for a specifc building, area or asset will then not be possible.

For more information about these modules see:

• Masterdata: Properties and areas module activation and information

• Masterdata: Assets module activation and information

4.2 Module activation

For this specific module activation, multiple settings and options apply:

Settings to be determined

• Use SLA times:

• Hide option to send request to contractor:

• Auto close request after workdays:

• Set update done by requestor flag:

• Use preferred suppliers:

• Use Knowledge base:

• Check duplicate problemtype:

• Check duplicate property:

• Check duplicate area:

• Check duplicate asset:

Service groups:

….

Emails:

The emails that are automatically send via the workflow (E.g. the confirmation email to the requestor after the new request is submitted) are also generated and shown in the include on the module activation after the module activation is started. It is possible to directly delete these emails if these emails are not desired.

The workflow emails that have been deleted, can always be regenerated by going to the workflow version and using the ‘Generate standard emails’ button. This will only generate the workflow emails that are currently not already present:

4.3 Data imports

When activating this module, some data imports become available, which can be used to quickly import relevant data into the system (as opposed to manually entering this data, which is also possible).

Relevant data imports become available in the module activation after the activation has been started. Default data imports can also be found on the admins startboard (only for level 2 and level 3 administrators).

For more information on data imports in general, see: Data imports

If the requests module is activated, the following default import connectors become available:

4.4 User groups

When a module is activated, user groups become available that can be assigned to user profiles. These user groups will give users access to (a subset of) navigation menu options, startboard tabs, and tasks in the relevant workflow(s).

For more general information on user profiles, system groups, users, and the user profile dashboard, see: User management

For the Requests module, the following user groups become available:

Via the 'User profile management' option on the administrator startboard, these user groups can be assigned to existing user profiles or add them to newly created user profiles.

4.4.1 Relevant user groups from other modules:

For some modules, other (master data) modules might be of importance, in order to be able to fully use this module.
For Requests, the Master data modules ‘Properties and areas’ and ‘Assets' are often relevant, therefore the following user groups could also need to be assigned to users (If not already done in the past), to be able to create and edit the relevant master data objects

When generating the user profiles, it is advised to also include these groups in the profiles or have dedicated profiles (and users) for these modules.

4.5 Navigation menu and startboard options

When a module is activated, the relevant navigation menu options become available to users with the correct authorizations (based on the user groups). Next to that, a module specific key user startboard tab becomes available for that particular module and is visible depending on the user's authorizations. This tab gives users insights and day-to-day work overviews relevant to the specific module.

For more general information on the navigation menu and startboard, see: [To be added Link+ content]

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

Screenshot navi 

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

Screenshot One startboard service group dashboard

5. Additional reports

For some modules, additional reports can be available via the ‘Report’ navigation menu option.

6. Additional settings and options after enabling

For some modules, additional settings can be configured after the initial module activation via the 'Module settings' option on the administrator startboard. A module is always activated with the most used settings pre-defined. After the module is activated, the module may have more advanced settings available, which can be managed via the Module settings as well.

To navigate to all Requests settings, go to Modules settings → tab Requests. Hover over the available settings to get more information:

Screenhot of Requests tab

7. Additional information

 …..

8. User manual

For the user manual with a more step-by-step explanation of the process itself, see: LINK

9. Q&A

=====================================================================

OLD part

Difficulty: novice

How to navigate to the module activation

To start the module activation for Requests:

1. navigate to the startBoard.

2. Click on the module activations tile.

3. Select the tab avalaible modules to roll out and select Standard Requests.

4. After selecting Standard Requests click Rollout selected module.

This will provide you with a short explanation like the one below.

After this a new page will open:

Steps to follow

Step 1 Adding the service desk service groups

To add service groups, navigate to the include at the bottom of the page and click Add service group. Give this service group a name. Examples of service groups could be: Facility Desk and IT.

The service groups are used to assign specific problemTypes, users are grouped within a service group and through their service group get Requests or Tasks assigned.

• What are service groups used for? For example, the problemType on broken coffee machines has the Facility Desk as service group. When a Request is submitted and the “broken coffee machine” problemType is select, all users within the Facility Desk will be able to handle/assign this Request. This logic is setup using the problem trees. Read all about problem types in this article: Problem tree/ problem type scheme.

Step 2 Settings to be determined

Step 3 Start module activation

What happens when clicking the green Start button in this wizard step?

• You move on to the next page of the Wizard.

• Workflow emails are automatically created. Meaning that we create the workflow emails that are send out when submitting/cancelling/closing Requests.

• Relevant imports are created, in the next step we will go over these imports.

Step 4 Check data and close the module activation.

On the next page we can check all items that have been created. This also contains a checklist we can follow.

• 

  In the example above we created two service groups: Facility Desk and IT. This results in the creation of two user groups with corresponding names.

• When adding these user groups to a user profile, requests assigned to this service groups can be handled by a user with this profile. These user groups should be added to at least one profile to be able to handle requests properly.

 Authorizations

The following groups can be assigned to users using the “User profile management” functionality. In addition to these groups, the groups that where created based on the Servicedesk service Groups need to be added to the user profiles.

Group	Reference	Comment
1. Create requests	GOB-G002	Group gives access to creating requests
4. Servicedesk employee	GOB-G013	Group gives the basic access to handle requests
4. servicegroups	GOB-G033	Group is used as a parent group, for all service groups relevant to a request. The service groups that are created in the SBR will appear under this parent group. These groups can be created via (Admin >) Setup > Processes > ‘Requests and ITIL’ > Include
5. Admin problem trees	FMB-G057	Group gives access to creating and managing the problem types within a problem tree
7. Management dashboards requests	FMB-G082	Group gives access to the menu option "Management dashboards" for the requests module, as well as access to the relevant objects to view this content of the dashboards.

An example of the Facility Desk/IT user profile is shown below.

User groups are always added to the user profiles to give access to functionalities. In addition, in the background, Workplace assigns group to users in the context of objects. An easy example is the group Requestor. A user that creates a request, gets the group 'Requestor in the context of that specific request. This group can than be used to assign access right or send emails to. Below an overview of these contextual group within the request module.

Group	Reference	Comment
6. requestor	GOB-G006	Group is automatically assigned to a user who is the requestor of an object and is given the relevant workflow tasks and required rights to the object
6. Service groups	GOB-G033	Users automatically get this group in the context of an object when a group they are a member of is set as the (current) group responsible for the object (request, workorder, etc)
6. employee service desk	GOB-G014	Group is automatically assigned within the context of a request to the user who is handling the request and gives the user the correct workflow tasks and authorizations
6. external performer	GOB-G015	Group is automatically assigned to the contractor in the context of a request or work order and used to give the user the correct rights in the request or work order
6. Requestor keep me posted	FMB-G047	If the requestor (in a request) indicated 'Keep me posted' (fmb-KeepMePosted) the fromContactId is added to this group (through scripting). All informative request emails go to this group

For importing data we take you through the basics steps on how to import module activation data. More details on imports can be found in this article Imports.

• Import files: The file that is created is for importing Problemtypes. To download the import template:

  • navigate to the “Relevant imports” include

  • Click Generate import template

  • Click the download icon next to the loop to download the template.

    • Tip: in the service Group column of the import file you can only use the service Groups that where defined in the first step of this wizard.

  • Send files to the client

• Import files receives and approved.

  • If relevant, check if objects are imported successfully.

    • View the created problemTypes via: navigationMenu ‘Requests' > menuoption ‘Problem type schemes’ > press the magifying glass in front of 'problemtree’

  • Click Upload import file and upload the import file obtained from the customer.

• To see what workflow emails have been created we navigate to the Generated workflow emails include. We can take a closer look at the individual emails by clicking on the hyperlinks but for more info on workflow emails check /wiki/spaces/KB/pages/25034763.

If everything is handled we can close the module activation by clicking the close button, Requests will now be shown as a NavigationMenu option.