Multi-site on Requests
An organization can have branches spread across different regions and sites of the globe to handle various specialized activities. In this globally distributed environment, a request can be raised from a site to a technician located in another branch 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 base configuration, the request module experiences an immense change.
If an organization has no branches and hence no sites configured, then while creating a new request then the default admin configurations gets applied to resolve the request.
Key entities in Request module
The admin configurations of the selected site in the new request form will get applied to the request.
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.
A request template with the group and technician pre-filled with values needs to be re-selected on choosing the requester, if the group/technician is not associated to the requester's site.
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 recalculated accordingly.
Technicians can view all the requests of a site if,
The technician is associated to the site and has the viewing permission as 'All' in Configuring Roles.
The technician is associated to the site with the viewing permission as 'All in associated sites'.
ServiceDesk Plus provides you with an option to bulk assign requests to technicians. The request can be assigned to the technician if,
The technician is associated to the site where the problem persists.
The technician has the permission to view the requests in all sites. This can be done in Configuring Roles.
If the technician is not associated to the site where the problem persist and if the technician has restricted view permissions then an error message occurs while assigning the request to the technician as shown below,
Scenario : Roles on Requests
A requester from London raises a demo related request persisting in Sydney through self-service portal of the ServiceDesk Plus application. By default, the admin configurations for London will be applied to the request. The request is handled by John, a technician in London. John can view and re-assign the request,
If John is only associated to London with the viewing permissions as 'All', then he will be able to view the requests in all the sites of the organization. He will be able to assign the request to technicians associated in other sites but if he assigned the request to himself, then the site field automatically changes to London.
If John is only associated to London with the viewing permissions as '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.
If John is associated to London and Sydney with the viewing permissions as '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 request to a technician in Sydney but not to technicians in other sites of the organization.
On 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 re-calculated. If Amy is assigned to a Group say, Support, then she can view and re-assign the request,
If Amy is associated to Sydney along with the viewing permissions as '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.
If Amy is associated to 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.