Archibus SaaS / Foundations / System Administration

Define How Workplace Requests are Processed (Manage Service Providers and Notifications)

This topic has the following sections:

Overview

In order for self-service users at your site to report maintenance problems and request services using the Archibus Workplace, you must define how the system will process these requests. Archibus uses service level agreements (SLAs) to control how a request is addressed. With Archibus Foundations, an SLA controls:

For example, when a self-service user requests a service such as paper shredding, the system looks up the SLA for paper shredding requests in this building and notes the service provider (employee or supervisor) who handles this type of issue. The SLA then routes this issue to the specified employee so that the issue can be addressed; the request appears on this user's Service Console. The SLA can optionally send a notification of the status to the requestor. An SLA can be refined based on the building to which it pertains. For example, you might have one contact and notification system for addressing paper shredding in the HQ, and a different contact and notification system for addressing paper shredding requests in the NC05 building.

Maintenance requests work similarly to the above description, except that they generate a work request. If you are using the Maintenance module in addition to Archibus Foundations, you can also manage the maintenance request as a work request in the Maintenance Console.

With Archibus Foundations, you define SLAs using the Foundations / System Administration / Manage Service Providers and Notifications task (ab-ess-sla-console.axvw). Use this task to create, edit, and delete SLAs.

Each SLA is based on a request type and optionally a maintenance problem type, such as MOLD, CEILING LEAK, GROUP MOVE, ELECTRICAL, and so on. Archibus ships with sample request types and problem types. You can review these samples and define new types using the Create Service Catalog and the Define Problem Types tasks.

Before working with SLAs, you should become familiar with the service request types and problem types defined for your site and check that any request type that you want to appear on Archibus Workplace has its "Active for Self-Service?" value set to Yes.

You must also define the employees, craftspersons, vendors, and users at your site so that these parties can receive notification of the request if they are the requestor or the internal service provider or external service provider defined in the SLA governing the request. All craftspersons, vendors, and employees must be registered in the Archibus Users table in order to receive email notifications generated by the SLAs. See:

Sample SLAs, Problem Types, and Request Types

Archibus comes with example SLAs, based on the sample request types and problem types. You can modify these for operations at your site. For example, you can edit one of the sample SLAs for a leaky faucet and add the particular employee at your site who should manage this problem. You can also copy an existing sample SLA to create your own SLA and change the sample values in the new SLA.

In general, it is recommended that an organization take a conservative approach when offering new services or automating the process around existing services. You can start by editing the provided SLAs and then gradually develop additional service request types, problem types, and SLAs as you analyze operations at your site and determine needs. If different parties are responsible for different services, you can differentiate the services by service provider.

Locate an SLA

Load the Foundations / System Administration / Manage Service Providers and Notifications task. Use the filter at the top of the view to search for an SLA. For example, the below image shows all SLAs specific to building NC05. Another handy search is to search by Request Type. For example, you might want to see all SLAs that pertain to group moves. Reviewing SLAs of the same request type can help you understand how the system routes service requests of a specific type.

Edit or create an SLA

To edit an SLA, click the pencil-shaped icon next to it. Create a new SLA with the Add New SLA button.

Complete the fields as follows: 

Field Description
Request Type

Choose the request type for which you are defining an SLA. (The values you can choose from are defined with the Define Service Request Types task.)

For example, you can specify how the system will route requests that pertain to office moves.

If editing an existing SLA, you cannot change this field.

Any request created for a Request Type that has an associated Problem Type will be handled by the Problem Type's SLA, not the Request Type's SLA. Therefore, do not define an SLA for a Request Type that has an associated Problem Type; instead, just define the SLA for the Problem Type.
Problem Type

If you chose a Request Type of SERVICE-DESK MAINTENANCE, complete this field to further define the type of maintenance request for which you are defining an SLA by choosing one or multiple values from the Problem Types list. For example, if three problem types are handled the exact same way, you can select all three from the pop-up list of problem types. The form may not have room to display all the characters of all three values, but once you save, you can click the field to see all the values.

For all other request types, this field is not editable.

If editing an existing SLA, you cannot change this field.

You can also handle maintenance issues and create service requests that generate work requests by completing the Problem Type field of a Request Type record. Then, create an SLA of SERVICE DESK - <YOUR REQUEST TYPE> and leave the Problem Type field of the SLA empty.

Building

Enter one or multiple buildings to which this SLA applies.

It is not mandatory that you complete this field. For example, if your site has two buildings and the request type will be handled the same way in both buildings, you can leave this field empty.

If editing an existing SLA, you cannot change this field.

Assign to Internal Service Provider

 This option will automatically be checked off because an SLA must be assigned to an employee.
Assigned to (Employee)

Choose an employee from the Employees table. This person is responsible for overseeing and managing the issue; they are the contact person for the issue. The employee that you enter in this option will view the request in the Service Console, where they can manage it: edit, approve, cancel, complete, and so on. Thus, be sure to enter the manager and contact for the issue, and not the employee who will actually execute the work.

For example, if leaks at your site are always handled by the in-house plumber but this employee does not manage the work and does not have access to the Service Console, you should not enter this in-house plumber in this field. Instead, you should enter the facility manager, or other party who manages work and has access to the Service Console.

If the issue will be handled by an external service provider (vendor), you can specify this in the next option, but you must still enter the internal employee who will oversee the vendor's work.

For maintenance requests, the employee that you enter here will be considered to be a supervisor.
Assign to External Service Provider

Some problems might be handled by external service providers, such as a pest extermination company. If so, check this option.

In these cases, the employee you specify in the above option oversees the external service provider. However, for informational purposes, you can optionally specify the external service provider that handles issues of this type by issue. This enables the vendor to receive email notifications about the status of the work, if you set Notify Service Provider?.
Assigned to (Vendor) If you checked Assign to External Service Provider, choose the provider from the Vendors table.
Notify Requestor?
 Set this to Yes if you want the requestor to receive notifications about the progress of the request.
Notify Service Provider? If set to Yes, the system generates email notifications for the service providers (employees and vendors). This requires that the vendor and employee be entered in the Archibus Users table and that the email addresses entered in the Archibus Users table match the addresses in the Employees and Vendors tables.

Create an SLA by copying

You may want to create multiple SLAs that are similar to one another. Rather than enter the information twice, you can create one SLA and then use it as the basis for a second SLA.

It is also useful to copy the sample SLAs and edit the copy to enter the an employee or building at your site.

  1. Load the Foundations / System Administration / Manage Service Providers and Notifications task.
  2. Locate the SLA that will serve as the basis for a new SLA.
  3. Click the Copy button (to the right of the pencil-shaped Edit button).
  4. The Copy SLA form appears, completed the values of the selected SLA.
  5. Edit the form's values to represent the SLA that you want to create.
  6. Click the Create button to save your edits and create an SLA.

SLAs for the default service types

You might notice that a service request has more steps than outlined in the above form for defining an SLA; for example, the service request may be routed for approval or may generate a move order -- options that are not specified in the above form. These steps occur because the SLAs for the default request types have a pre-defined operation that you cannot change. This operation is outlined in the below table.

Also note that the SLAs for default service types are always active. In the Define Service Request Types task, you cannot activate and deactivate these request types.

In the following table, note that:

Request Type Approve Step Issue Step Notify
SERVICE DESK - INDIVIDUAL MOVE Approval step required

Auto-issue (after approval)

Auto-create move order

Requestor

Service Provider

SERVICE DESK - GROUP MOVE Approval step required

Auto-issue (after approval)

Auto-create move order with related project info

Requestor

Service Provider

Supervisor
SERVICE DESK - HOTELING Auto-approve Auto-issue

Requestor

Supervisor
SERVICE DESK - MAINTENANCE Approval step required Auto-issue (after approval)

Requestor

Service Provider

Supervisor

For any type of request that you create with the Define Service Request Types task the process is:

Examples

A typical way to get started with Archibus Foundations is to experiment with the sample database by creating requests in Archibus Workplace and then managing them in Service Console. Going through the following examples will help you understand the routing process. If you find that a request does not appear in Service Console, examining the SLAs for this Request Type will show you how the request was routed and why it does not appear in your Service Console. For example, perhaps the SLA calls for routing the request to user AFM-MOD and you are logged in as AFM-FDN. In this case, the request will not appear in your queue in Service Console.

The following examples assume that you are working with the sample HQ database.

Note: The below examples focus on requests being routed to sample users AFM-EMM and AFM-FDN and appearing in these users' Service Console. If a user additionally has access to the Maintenance Console and/or Move Console, the requests would appear in both Service Console and these tools.

Request working space in building NC05

  1. In Workplace, user AFM-EM requests working space (hoteling space) in building NC05 for Paul Abbott.
  2. The system consults the SLAs for the SERVICE DESK - HOTELING request type.

  3. The system notes that there is an SLA specific to building NC05, the building which the user has requested, and that user AFM-FDN handles these requests.
  4. The working space (hoteling) request appears in the Service Console for user AFM-FDN.
  5. If the Notify Requestor? option has been set for this SLA, user Paul Abbot receives an email about the status of the request.

Request working space in building NC04

  1. In Workplace, user AFM-EM requests working space in building NC04 for themselves.
  2. The system consults the SLAs for the SERVICE DESK - HOTELING request type.
  3. The system notes that there is no SLA specific to building NC04, the building which the user has requested. Therefore, the SLA consults the general SLA for the SERVICE DESK - HOTELING request type (it has no building association) and notes that user AFM-MOD handles these requests.
  4. The working space (hoteling) request appears in the Service Console for user AFM-MOD.
  5. If the Notify Requestor? option has been set for this SLA, user AFM-EM receives an email about the status of the request.

Request a move to building NC05

For moves, it is the destination building (and not the building where the employee is currently located) that determines the SLA that governs the request.

  1. In the manager edition of Workplace, user AFM-EM requests to move employee Joanne Abbers, who resides in room SRL-02-267, to room NCO5-02-2209.
  2. The system consults the SLAs for the SERVICE DESK - INDIVIDUAL MOVE request type.


  3. The system notes that there is an SLA for individual moves that is specific to building NC05 (the destination building), and that user AFM-FDN handles these requests.
  4. The individual move request appears in the Service Console for user AFM-FDN.
  5. If the Notify Requestor? option has been set for this SLA, user AFM-FDN receives an email about the status of the request.

Request a group move that includes a move to building SRL



  1. In the manager edition of Workplace, user AFM-EM requests a group move, and adds three employees to move to NC05. User AFM-EM then requests to move employee Joanne Abbers, who resides in room SRL-02-267, to room SRL-04-138.
  2. The system consults the SLAs for the SERVICE DESK - GROUP MOVE request type.
  3. The system notes that the group move request contains a mixture of moves to SRL and NC05. Therefore, it cannot use the SLA specific to building NC05. The SLA consults the general SLA for the SERVICE DESK - GROUP MOVE request type (it has no building association) and notes that user AFM-MOD handles these requests.
  4. The group move request appears in the Service Console for user AFM-MOD.
  5. If the Notify Requestor? option has been set for this SLA, user AEM receives an email about the status of the request.

Request maintenance work in building

Suppose you create an SLA for handling plumbing in building SRL, in which you specify the vendor that will do the work and user AEM will oversee the work.

Suppose craftsperson WILL TRAM  notices a plumbing issue in the basement of building SRL.

  1. In Archibus Workplace, Will Tram chooses General Maintenance / Plumbing and completes the form with the basement floor in building SRL.
  2. The system consults the SLAs for the SERVICE DESK - MAINTENANCE request type PLUMBING, and notes the above SLA which is specific to building SRL.
  3. The system notes that the internal service provider is user AEM.
  4. The system routes the maintenance request to user AEM and it appears in the Service Console for user AEM.
  5. User AEM will coordinate with vendor WHOLE WATER, who will execute the work. AEM will supervise the work and monitor its progress using the Service Console's features.
  6. Craftsperson WILL TRAM (as requestor), vendor WHOLE WATER, and user AEM will receive email notifications about the progress of this work request. In order to receive the email notification, craftsperson WILL TRAM and vendor WHOLE WATER must also be entered in the Archibus Users table with email addresses that match their entries in the Craftspersons and Vendors tables.

For more information on SLAs for maintenance requests, see Understanding Requests for Maintenance Work.