[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

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.

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: Enable this option to register the response and handle times desired per priority and being able to report on the reponse and handle times for all requests.

• Hide option to send request to contractor: Hide the option if requests can be forwarded to a contractor. This option can be used if the customer does not use corrective work orders for this purpose.

• Auto close request after workdays: After a request is handled, the requestor can check if the request is handled accordingly. If the requestor does not review the request, the request is automatically closed after X days.

• Set update done by requestor flag: Enable this option if the requests needs to be flagged as soon as the requestor adds more information to the request. The service group which handles the request is aware of the additional information and can mark the request to configrm that the requestors update is seen.

• Use preferred suppliers: Enable this option to register preferred suppliers in general, per building, per area and/or per asset and let the application automatically assign the preferred supplier to the corrective work orders.

• Use Knowledge base: Enable this option to use a knowledge base in requests, where users can add knowledge base items to help other users handling requests faster and more efficient.

• Check duplicate problemtype: Enable this option to let the application check for duplicate (open) request with the same problemtype.

• Check duplicate property: Enable this option to let the application check for duplicate (open) request with the same property/building.

• Check duplicate area: Enable this option to let the application check for duplicate (open) request with the same area.

• Check duplicate asset: Enable this option to let the application check for duplicate (open) request with the same asset.

Service groups:

Create the desired service groups from the module activations Service group include. At least one service group needs to be created to be able to start the module activation.

Workflow 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. If the customer does not want to use one or more workflow emails, the emails can directly be deleted from the overview. For more information on workflow emails: Workflow emails

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: https://spacewell.atlassian.net/wiki/spaces/KB/pages/441712705/Authorizing+users#2.2-Navigation-menu-and-Startboard

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

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

This tab is available for the following user groups:

• Servicedesk employee

• Management dashboards requests

This startboard tab has some buttons that are 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 assgined to me: This overview shows requests assigned to me to handle.

5. Additional reports

For some modules, additional reports can be available via the ‘Reports’ navigation menu option.
For the requests module, there are reports available via:

• Navigation menu reports: A long list of reports related to requests available for all service groups.

• Management dashboard: A management dashboard for requests is available in the ‘Requests’ navigation menu for the ‘Management dashboards requests’ system group, with overviews and graphs related to requests (New vs handled, SLA response times, etc):

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:

7. Additional information

No additional information currently.

8. User manual

For the user manual with a more step-by-step explanation of the process itself, see: Requests module for (end)users

9. Q&A

Waiting for questions to answer.

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

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.