Multi-Site Guidelines for Requests

Multi-Site Guidelines for Requests

An organization can have branches spread across different regions and sites globally to handle various specialized activities.

In this globally distributed environment, a request can be raised from one site to a technician located at another site of the organization.

The request is resolved based on the admin configurations (operational hours, holidays, SLA, and business rules) of the site from which the request was raised. Hence, with site-based configuration, the request module experiences immense change.

If an organization has no branches and hence no sites configured, then when creating a new request, the default admin configurations are applied to resolve the request.
 

Creating Requests 

  1. The admin configurations of the selected site in the new request form are applied to the request.
  2. The groups and technicians corresponding to the selected site will be listed. Groups act as a filter in choosing the technician to resolve the request.
  3. A request template with the group and technician pre-filled with values needs to be re-selected when choosing the requester if the group/technician is not associated with the requester's site.
 

Editing Requests 

  1. If a request needs to be routed to a technician in another site, then on selecting the site, the SLAs and business rules for the site will be applied, and the due-by time is recalculated accordingly.
 

Viewing Requests 

Technicians can view all the requests of a site if,
  1. The technician is associated with the site and has the viewing permission set to All when configuring roles.
  2. The technician is associated with the site with the viewing permission set to All in associated sites.
 

Assigning Technicians 

ServiceDesk Plus MSP Cloud application provides an option to bulk assign requests to technicians. The request can be assigned to the technician if,
  1. The technician is associated with the site where the problem persists.
  2. The technician has permission to view the requests of all sites. This can be set in configuring roles.
  3. If the technician is not associated with the site where the problem persists and has restricted view permissions, then an error message occurs while assigning the request to the technician.
 

Scenario - Roles on Requests

A requester from London raises a demo-related request persisting in Sydney through the Requester Portal. By default, the admin configurations for London will be applied to the request. John, a technician in London, handles the request. John can view and re-assign the request:
  1. If John is only associated with London with viewing permissions set to All, then he will be able to view requests of all the sites in the organization. He will be able to assign the request to technicians associated with other sites, but if he assigns the request to himself, then the site field automatically changes to London.
  2. If John is only associated with London with viewing permissions set to All in associated sites, then he will be able to view all the requests raised in London. He will not have the privilege to re-assign the request to technicians in other sites.
  3. If John is associated with both London and Sydney with viewing permissions set to All in associated sites, then he will be able to view all the requests raised in London and Sydney. He can re-assign the request to a technician in Sydney but not to technicians in other sites of the organization.
Upon assigning the request to Amy, the technician in Sydney, the SLAs and business rules configured for Sydney will be applied to the request, and the due-by time recalculated. If Amy is assigned to a Group, say Support, then she can view and re-assign the request:
  1. If Amy is associated with Sydney along with viewing permissions set to All in Group and assigned to him, then she will be able to view all the requests raised in the groups to which she is assigned.
  2. If Amy is associated with both Sydney and London with the viewing permission All his requests, then she will be able to view only the requests assigned to her. She will be able to re-assign the requests to other technicians in London and Sydney but will not be able to view the request as it does not fall under their permitted scope.

    • Related Articles

    • Edit Requests

      Role Required: Technicians with permission to edit requests Edit an Individual Request Go to Requests and choose the respective customer from the drop-down in the header. Open the request that you want to edit. Click Edit at the top of the page to ...

    • Link Requests

      Technicians can link closely associated requests by designating a parent request and linking other requests to it. Allow Automatic Selection of the Parent Request Go to Requests and choose the respective customer from the drop-down in the header. In ...

    • Delete Requests

      Role Required: Technicians with permission to Delete requests Delete an Individual Request Go to Requests and choose the respective customer from the drop-down in the header. Click the subject of the request to open it. In the request details page, ...

    • Search Requests

      In the Requests module, you can search through various fields, attachment names, merged request IDs, descriptions, conversations (excluding automated responses), and notes. This includes all Active, Trashed, and Archived requests. Search results can ...

    • Close Requests

      Requesters and technicians can close requests that have been addressed and resolved. Role Required: Technicians with Close Request permission; Requesters Closing a Request as a Requester A requester can close a resolved request by opening it and ...