Auto Assignment

When a new request comes, it is an open request, and not assigned to any technician. To prevent a pile of unattended requests, you can automatically assign them to the desired technicians. The system filters a set of technicians before applying the logic.

The conditions to filter the technicians are:

  • Based on the Technician Group: If the technician group is selected, the system will consider all the technicians in that group for Auto Assignment.
  • Based on the Technician Assigned: If the assignee is not defined, then only Auto Assignment will evaluate the request.
  • Based on Roles and Permissions: If no group or assignee is defined, the system will consider all the technicians who can access the request (even a small edit privilege is enough).
  • Based on Excluded List: The system will not consider the technicians listed in the excluded list.

Configurations

To configure the Auto Assignment settings,
Navigate to Admin > Automation > Auto Assignment and the page appears.

Auto Assignment Menu
Auto Assignment Menu
Auto Assignment Settings
Auto Assignment Settings

You can set the following options:

  • Manual: The system will not do anything when a new request comes. Technicians have to manually investigate the requests and assign to fellow technicians.
  • Round Robin: The system will assign the request to all the technicians one by one in a round robin fashion. For example: If there are 5 technicians, the system will assign 5 requests one by one to each technician. For the 6th request, again the system will start assigning to the first technician.
  • Smart Balance: The system will assign the request to the technician who has the least number of opened requests.
  • Excluded Technicians: You can select the Technicians you wish to exclude from getting the tickets assigned automatically.
  • Consider only Logged in Technicians: Enable this flag if you wish to consider only those technicians who are ‘Logged In’ for the Auto Assignment.

Once done, click Update, and the settings will get applied to the new requests.

Notes:

  • The Auto Assignment works only on the new requests. It does not assign technicians to the existing open tickets.
  • The Auto Assignment should be a one time job and set while configuring the system. Doing it at a later stage can leave a huge pile of requests unattended.
  • For both Round Robin and Smart Balance only logged in technicians will be considered in Auto Assignment if the flag is Enabled. By default, it is disabled.
  • The Smart Balance will function only if the Support Level is assigned to a technician from Admin > User > Technicians page.
  • The option set over here will be overridden if a Workflow or Scenario related to Auto Assignment is configured.

Event Notifications

Event notifications are essential for the day to day operations and with predefined templates the users can readily use them. The templates save a lot of time required for writing and editing the email or an SMS. Also, with placeholders contained in the templates an email or SMS can have all the required details. Thus, you can control the template’s content and ensure that proper communication takes place at important events.

To view the Event Notifications page, navigate to Admin > Automation > Event Notifications.

Event Notifications Page
Event Notifications Page

The page provides the following three tabs:

  • Email Notification: Enables you to edit the default email templates. These are used to send notifications to the recipients when an event is triggered.
  • SMS Notification: Enables you to edit the default SMS templates. These are used to send notifications to the recipients when an event is triggered.
  • SMS Gateway Configuration: Enables you to configure the SMS Gateway for sending SMS notifications.

Approval Settings

Approval Settings apply at the global level for all the approvals in the modules. It means, the settings are irrespective of the nature of module, ticket, or the approval request. You can manage the settings from the list page.

Approval Settings link
Approval Settings link
Approval Settings
Approval Settings
Parameter Description
Multi Approval Decision Type When there are multiple approval workflows available for a ticket, the decision depends on the number of approvals that needs to be accepted. The options are:

  • Unanimous: All the approvals should be accepted.
  • Majority: More than 50% of approvals should be accepted.
  • Any one: Any one approval is sufficient.
  • Last Approval: The approval is taken based on the highest priority workflow. The one located on the top of all the workflows is considered to have the highest priority.
Allow User to Create Manual Activate if you want to allow the user to create an approval request manually. If enabled, you can create an approval from the ticket’s details page. If disabled, on clicking Ask For Approval from the details page, the system will automatically apply the suitable approval workflow.
Note Required for Approval Rejection Activate if you want the approver to add a note on rejecting the approval.
Change Request Status To Define the request status to be changed as per the stages of the approval workflow.
Change Problem Status To Define the problem status to be changed as per the stages of the approval workflow.
Change Asset Status To Define the asset status to be changed as per the stages of the approval workflow.

Once all the settings are configured, click Update.

Create Approval Workflow

The page helps you to create an approval workflow using which the requests can be sent for approval to the concerned approvers automatically.

To create an approval workflow, click the Create Approval Workflow button on the top-right corner of the page.

Create Approval Workflow button
Create Approval Workflow button
Create Approval Workflow
Create Approval Workflow

Enter the following details:

  • Approval Workflow Name: Enter the name of the workflow.
  • Module: Select the module on which the workflow should function.
  • Condition
    Condition statements are compared against the ticket parameters for a workflow to qualify. By default some condition parameters are available for use. You can also add new parameters in the condition list by adding custom fields in the form of the respective modules. For example: Request Form, Change Form, Problem Form, etc.
Condition Statements
Condition Statements

A condition has 3 sections. A condition parameter, an operator, and a value. In the parameter you select the field that is under evaluation. The operator decides how the field will be evaluated. The value of the field is matched with the value of the condition. Also, you can join 2 condition statements using AND/OR operators.

Approvals

An approver is the person who Approves or Rejects the request. The approver can be a specific person, a member of a group, or any one in the organization.

Define Approvers
Define Approvers
  • Set Individual Decision Type: This indicates the way you want to evaluate the approval. The options are:
    • Unanimous: If selected, the request should be approved from ALL the approvers.
    • Majority: If selected, more than 50% approvals are required.
    • Anyone: If selected, even a single approval is sufficient. This is useful when there are more than 1 approvers.
    • First Approval: If selected, the first approval received (Approved or Reject) will be considered and the rest will be ignored. For example, If 3 approvers are set and if the first approval received is Approved, then this is considered. The approvals from the rest of the approvers will be Ignored, though rejection is received later from other approvers.
  • Requester Group: Select the requester group if they are responsible to approve something in the ticket. For example: If a technician wants a remote access, anybody in the requester group can approve the request.
  • Technician Group: Select the technician group if all the people should or can approve something in the ticket. For example: If you need access to a specific website, anybody in the IT team can approve the request.
  • Set Approvers To: Select the specific persons (technicians and requesters) if they are responsible to approve something. You can select more than one approver.
  • Requester’s Manager: Enable if you need an approval from the requester’s manager.
  • Assignee’s Manager: Enable if you need an approval from the assignee’s manager.
  • Department Head: Enable if you need an approval from the department’s head.
  • Subject: Enter the subject of the approval request. It appears on the details page of the ticket, logs, emails, etc.
  • Description: Enter the description that helps the approvers to get a detailed information about the request so they can make an informed decision.
  • Add Stage: Click to add a new stage (level) for approval. If clicked, configure the next level of approval for the tickets.

Adding Approval Stages

Adding an approval stage means someone else has to approve a request after the previous is approved. In the ticket, the stages are visible with numbers in the Approvals tab as shown below.

Approval Stages
Approval Stages

List Page

The list page displays all the approvals for Request, Problem, Change, Release, Asset, Asset Movement, Knowledge, and Purchase modules respectively.

To view the Approvals list page, navigate to Admin > Automation > Approval Workflow.

Approval Workflow Option in Admin Settings
Approval Workflow Option in Admin Settings
Approval Workflows List Page
Approval Workflows List Page

The page provides the following features:

  1. Search: Search the workflows using keywords across all the modules. You can view the result by clicking on the respective tabs.
  2. Modules: Select the module based on which you want to view the workflows.
  3. Approval Setting: View and configure the approval settings.
  4. Create Approval Workflow: Create a new approval workflow.
  5. Enable/Disable: Enable or disable the workflows that you want to use or do not want to use. By default, a new workflow is always in enabled state.
  6. Change Priority: Change the priority of the workflow. They will execute as per the order.
  7. Duplicate: Use the existing workflow to create a new one. It helps in modifying the existing workflow without breaking it.
  8. Edit: Edit the existing workflow to make changes in it. The page is exactly similar to the create page.
  9. Delete: Delete the workflow if not required.

Example Scenario

To understood an SLA, a small case scenario can be considered. The objective of this scenario is only to explain the flow of SLA and not all the features associated with it. Here, you can see:

  • How SLA computes the due date.
  • Calculation of due date.
  • Escalations on SLA violation.

The SLA is created with the following settings:

  • Name: Low Impact SLA for Demo.
  • Operational Hours Type: Business – should be applicable until a technician group is assigned. And, also when the technician group is assigned but the latter is not associated with the business hours.
  • Condition: SLA is effective when the request Impact is Low.
  • Response Escalation: Change Priority to Medium.
  • Max Response Time: 10 minutes
  • Max Resolution Time: 15 minutes
  • Resolution Escalation: Send Escalation Email and set Priority to High.
  • Operational Level Agreement: 6 minutes
  • Technician Group: IT
Example for Sample SLA
Example for Sample SLA

Now, create a request of Low priority. The SLA will get applied to it as shown below.

SLA applied to Request
SLA applied to Request

Since, there is no technician group assigned to the request, it has taken the ‘Default’ business hours for due date computation. Default business hours is Mon-Fri 10:00 AM to 06:00 PM. The creation time is 7th Jul 2022 11:36 AM. Also, the resolution time is 10 minutes i.e. 7th Jul 2022 11:51 AM.

The SLA after the due is escalated and the urgency is now set to medium. It also shows the over due period.

SLA Overdue
SLA Overdue

Now, assign a Technician Group to the request. The Technician Group has 24×7 working hours associated to it. Based on this calculation, the 15 minutes resolution time ends 15 minutes after the request create date. Hence, the overdue period is changed accordingly. Since, the create date was Jul 07, 2020 11:36 AM, the due date for technician group was 15 minutes later i.e. Jul 07, 2022 11:51 AM.

SLA with Technician Group Business Hours
SLA with Technician Group Business Hours

Now, when the Operational Level Agreement is set to 6 minutes, and a Technician Group is assigned, the rule gets applied as shown below.

OLA Applied
OLA Applied

Since, the OLA was applied on Jul 07, 2022 12:30 PM, its due date will be after 6 minutes, i.e., Jul 07, 20222 12:36 PM

If the OLA rule gets violated, the field displays the OLA Overdue by time in red color as shown below.

OLA Overdue
OLA Overdue

Service Level Agreement

Service Level Agreements define the commitment between Requestors and the IT service provider in an organization. SLAs determine the level of urgency, response time, and the time required for tickets to get resolved, and they also govern the escalation rules when tickets are not resolved or responded within a stipulated time frame. SLAs can be set for a department and a sub-department.

By default we have four SLAs defined out of the box with each having their own rules for resolution and escalation time. The default SLAs are defined for the Request module and are triggered based on the Priority.

  • Low Priority
  • Medium Priority
  • High Priority
  • Urgent Priority

How SLA Works

SLA requires a collaboration of different configuration settings. Based on the configuration, the SLA assigns a ‘Due date’ to the ticket. For example: An SLA is defined for the low priority ticket. Its due date is 7 days. System will see the ticket create date and compute the due date after adding 7 days.

SLA evaluates the working business hours of the technician group. For example: A technician group – ‘support team’ works for 24×7 hours. For a low priority request, the system will compute 7 days by adding all the working hours to give a due date. Hence, if a ticket opens on 1st Jan 2020 at 10:00 AM in the morning, system will show due date as 8th Jan 2020 10:00 AM (6 Days 23 Hours minutes 59 Minutes).

In another scenario, a technician group – ‘IT Team’ works Mon-Fri 10:00 AM – 07:00 PM. Also, they enjoy 1 hour lunch break. For a low priority request, the system will compute 7 days by adding all the working hours (it excludes weekend breaks and lunch break) to give a due date. Hence, if a ticket opens on 1st Jan 2020 at 10:00 AM in the morning, the system will show due date as 10th Jan 2020 06:00 PM (8 Days 23 Hours 59 Minutes). Here, it does not calculate the hours and only computes the number of working days. Hence, the due date is the end of the day and not 10:00 AM in the morning.

When someone fails to resolve the request on time, it results in SLA violation. The system kicks the escalations flow and the actions defined in escalation comes into effect.

Create SLA

The create page helps you to create an SLA with custom conditions and rules. To create an SLA, on the list page, click the Create SLA button on the top-right corner, and the page appears.

Create SLA button
Create SLA button
Create SLA Page
Create SLA Page

Enter the following details:

  • SLA Name: Enter the SLA name.
  • Module: Select the module on which the SLA should work. The options are: Request, Problem, Change, and Release.
  • Operational Hours Type: Select the operational hours based on which the SLA will be calculated. The options are:
    • Calendar Hours: The SLA takes 24×7 as the working hours.
    • Business Hours: The SLA uses the settings from business hours section.
  • Description: Enter the detailed description about the SLA. This field helps other people to know exactly what is the SLA about and what could be its implications.
  • Conditions: Define the conditions here that will be evaluated in the request to apply the SLA. You can define multiple conditions here. All the conditions work in AND form. It means the SLA is applicable only when all the conditions are true.
Adding Conditions in SLA
Adding Conditions in SLA
    • Condition Parameter: Select a condition parameter from the dropdown list.
    • Operator: Select the operator: In/Not In from the dropdown list.
    • Value: Select the value for condition. You can select multiple values of which the first value will be displayed in full, followed by the count of all additional values selected.

You can also click the Add Condition Group button to add more conditions in the SLA. Click on Remove All Conditions to remove all the conditions of the SLA.

  • Max Response Time: Enter or select the maximum response time and unit for the technician to respond. The values can be whole numbers only. The units can be minutes, hours, and days. In case minutes is selected, the response time must be 5 or more.
    • Add Escalation in Response Time: When someone fails to give a response in the SLA defined time frame, the escalation rule will apply. You can add only 1 level of escalation.
Response Escalation
Response Escalation
    • Before/After: Select the time when the escalation should take place. For example: In the above figure, the escalation will take place before 5 minutes of response due date time.
    • Actions: Select the actions from the given list. In the above figure, the priority of the request will set to High and Impact to On Users.
  • Max Resolution Time: Select the maximum resolution time value and unit. Values can be whole numbers only. The units can be minutes, hours, and days. The resolution time is always equal to or higher than response time. In case of minutes unit, the value must be 5 or more.
  • Add Escalation in Resolution Time: When someone fails to resolve the request in the SLA defined time frame, the escalation rule will apply. You can add up to 5 levels of escalation.
Resolution Escalation
Resolution Escalation
  • Before/After: Select the time when the escalation should take place. For example: In the above figure, the 1st escalation will take place after 10 minutes of resolution due date time. The 2nd escalation will take place after the time of first level escalation is over.
  • Actions: Select the actions from the given list. In the above figure, the impact of the request will set to On Department. In 2nd escalation, the technician group will be set to IT.
Operational Level Agreement (OLA)
Operational Level Agreement (OLA)
  • Operational Level Agreement (OLA): OLA defines the timeline for each individual technician group. It is defined per SLA and is optional. It works similar to SLA but includes only the working hours of the technician group. OLA time should be less than or equal to the Max Resolution Time.

To configure OLA,

  1. Enable the OLA option.
  2. Click the Add Operational Level Agreement button and specify the time. Values can be whole numbers only. The units can be minutes, hours, and days. In case of minutes unit, the value must be 5 or more.
  3. Select the Technician Groups to whom you want to apply the OLA rule. You can select multiple groups.
  4. You can click the Add Operational Level Agreement (OLA) button to add more OLAs in the SLA. You can add up to 5 levels of OLAs.

Once all the details are filled, click Create, and the SLA gets created. By default, it is enabled.

SLA List Page

The list page displays all the SLAs available in the system.

To view the list page, navigate to Admin > Automation > SLA.

SLA Option
SLA Option
SLA List
SLA List

The page provides the following features:

  1. Search: You can enter a word and search for the required SLA that contains the text. The system displays a list of SLAs that contains the word.
  2. Create SLA: You can create an SLA.
  3. Grid: You can view the details of the SLA in the grid.
  4. Enable/Disable SLA: You can enable or disable an SLA from the list. Enable the SLA to use it. Disable the SLA if you do not want the system to use it.
  5. Change Priority: You can change the priority of the SLA by moving the snowflakes icon up or down. When more than 1 SLA passes the evaluation condition, the system takes the first SLA (from the top), and applies it to the request. The 2nd SLA will be evaluated only when the 1st SLA conditions are not applicable anymore.
  6. Duplicate: You can create a duplicate SLA of an existing SLA with the same settings.
  7. Edit: You can edit the required SLA using the edit icon.
  8. Delete: You can delete the SLA(s) if no longer required. The default SLA can only be edited and not deleted.

Understanding SLA Priority

Here, the scenario what happens when more than 1 SLA is applicable in a request is considered.
For Example: There are 2 SLAs available: A Low Priority SLA and a Low Impact SLA.

Example Scenario for SLA
Example Scenario for SLA

According to the rule, if both the SLAs qualify, the first SLA from the top shall only be applicable. To test this, a request with low priority and low impact is created. The audit trail displays that low impact SLA is applied on the request.

Low Impact SLA applied on Request
Low Impact SLA applied on Request

Now, change the Impact of the request from ‘Low’ to ‘On Users’. The low priority SLA is applied on the request. The due date of the request will be computed using its created date.

Low Priority SLA applied
Low Priority SLA applied

Whenever you make a change in the request, the system again evaluates all the SLAs and applies the first fitting SLA. Some important facts about the SLA are:

  • Due date of any request is calculated only on its created date.
  • Every time you make a change in the request, the system evaluates the best applicable SLA and applies to the request. Even the new SLA will use request’s created date to compute the due date.
  • As an admin, you should be very careful with the enabled SLAs and their order.

Example Scenario 2

To understand the Run Webhook workflow, you can consider the following scenario:

Create a workflow with the following statements:

  • Name: Run Webhook when location is not Asia.
  • Trigger Statement: When IP Address is changed.
  • Action for trigger statement: Run Webhook.
Run Webhook Workflow Scenario
Run Webhook Workflow Scenario

In the Run Webhook Action editor, configure the following parameters:

Run Webhook Action parameters
Run Webhook Action parameters
Parameter Description
Request Type Select the request type as Get or Post.
URL Enter the URL using which the Webhook will run.
Secure API Enable if the API is a secured API. If enabled, enter the username and password. By default, disabled.
Output Mappings
  • Key: Select the key to be mapped with the output.
  • Value: Enter the value of the key to be mapped.
Description Enter the description of the Webhook.

Once the details are filled, click done, and save the workflow.

Now, when the IP Address is changed, the Webhook gets executed, and you get to know from where the user has signed-in to the system.

Webhooks are API services that provide information whenever an event is triggered. Thus, with the help of this scenario you can track the location of the users.