When a Change Request (RFC) is logged within the system, it is allocated to the Team that is associated with the SLA and Workflows used by the RFC or to the default Team assigned to a Workflow State. The RFC Status is automatically set to the default Entry State of the Workflow.
The
appropriate Change Request Workflow is assigned within the Change Request
Summary tab, by selecting an option from the Workflows drop-down list.
This list is derived from the SLA assigned to the Customer, Organizational
Unit and Item. Once the Workflow is selected, the associated Teams are
available for assignment. Based on the Team assigned, a Technician
in the Group associated with the first State of the selected Workflow
is allocated to work on the RFC. This can be adjusted manually, if required.
As the RFC moves through the Workflow, it is allocated to an Assigned
Technician within the Group associated with the assigned State.
Note, that if the Technician assigned to the RFC is also included in the
Group associated with the next Workflow State, the system will by default
reassign the RFC to the same Technician when it moves to that next State.
It should also be noted that for each Change Request Team, there is an
over-arching layer of escalation above the Technicians assigned to each
Workflow State. This means that throughout the Workflow Lifecycle, in
addition to changing the Technician by moving Workflow States, the RFC
can be escalated to a higher level of support if required.
The Request is automatically escalated according to the SLA assigned to the RFC and the triggers configured within the Priority of the SLA. An RFC is escalated if the assigned User exceeds the Escalation trigger point defined for the Response, Restoration or Resolution time of the assigned SLA, when the assigned Workflow State is an SLA Active State. Or, it can be manually escalated by a User, if required.
When an RFC is assigned to a User, the system follows a series of steps to look for the most appropriate Technician for the job, based on skill set, location and workload. The order of business logic is as follows:
The system will identify the Team associated with the Service Request's SLA and associated Workflows
The system will find Technicians/Supervisors assigned to the Team
If Users are assigned to an Organizational Unit, the system will identify the Users that belong to the same Organizational Unit as associated with the Request by the Customer assignment
If Classifications/Skills are assigned to Users, the system will find Technicians/Supervisors assigned to the Request's selected Classification
Based on the Team configuration, if the Live Priority option is enabled for the Team, the system will look for a User who is logged into the system
The system verifies Work Hours/Availability of Users within the Team for appropriate Request assignment
The system will assign the Request to the User who has the lowest workload, i.e., the fewest number of Open or Pending Requests
If there is a tie, the system randomly allocates the Request to a User in the tie.
If a more appropriate Team member is available, the User assigned to the RFC can re-assign it manually by selecting a Technician from the drop-down Technician list in the Change Information screen.
Note, if the Self Assign option is enabled for the Team, the system assignment logic is ignored and the User creating the request is automatically assigned the RFC.
An RFC's Service Level Agreement includes trigger points that set the rate at which automated escalations will occur for an RFC. Auto-escalation is triggered when the number of support hours specified for either an RFC's Service Level Response, Restoration or Resolution time is exceeded and the SLA Trigger action is set to Escalate. When it is escalated, the RFC is assigned to a Technician or Supervisor in the over-arching escalation layer for the assigned Change Team.
The Escalate button next to the Technician name in the Change Request Information Summary Screen, escalates the RFC to an over-arching escalation layer for the Change Team. Any Technician assigned within the escalation layer can be assigned to the RFC.
If the Escalation Control functionality is enabled in Admin>Setup>Privileges>Requests, there is the option to enable or disable escalation within the Change Request Information Summary screen.
This option is only visible to Supervisor Users. Once an RFC is created, a Supervisor can elect to switch the Escalation option to Off. This means all SLA timers stop, which prevents escalation. Switching the option back to On will re-start the timer and reactivate the SLA triggers.