Step-by-Step Administrator Guide

This guide covers two related workflows for SLA Policy (V2):

• Part 1 — Creating and Managing a Single SLA Policy: building one policy from scratch using the wizard, then activating or deactivating it.
• Part 2 — Bulk Uploading SLA Policies: importing many policies at once from a CSV file, validating them, fixing errors, and appending them to your existing list.

Each part is written so you can follow it in order.

---

Part 1 — Creating and Managing a Single SLA Policy

This part walks you through creating, configuring, and managing an SLA Policy (V2) end to end. It covers where to find the feature, how to define which tickets a policy applies to, how tickets are assigned, how escalations are set up, and how to activate or deactivate a policy. Each step is written so you can follow it in order, from a blank policy to a live one.

Before You Begin

A few things that help the rest of the guide make sense:

• You need an admin account. SLA configuration screens are restricted to authorized administrators.
• A policy moves through three states: Draft (saved but not live), Active (live and matching tickets), and Inactive (saved but switched off).
• The creation flow is a wizard with five configuration stages followed by activation. You can move forward with Next and save at the end with Create.

---

Step 1 — Access SLA Policy V2

1. Log in with your admin account.
2. Navigate to Settings.
3. In the Settings area, locate and open SLA Policy V2.

On this page you can see your existing policies, grouped by status:

• Active — policies currently live and applied to tickets.
• Inactive — policies that exist but are switched off.
• Draft — policies you started but have not finalized.

---

Step 2 — Start Creating a New SLA Policy

1. Click Create at the top-right corner of the SLA Policy V2 page.
2. Enter a name for the policy, for example "Test SLA V2".
3. Optionally, add a clear description so other admins understand the policy's purpose.
4. Click Next to proceed.

Tip: A descriptive name and description are worth the few extra seconds. When you have many policies, the list is far easier to manage.

---

Step 3 — Select Department and Define Rule Scope

This step decides which tickets the policy will apply to. You define a department first, then narrow the scope with rules.

3.1 Choose the Department

1. Select the department this SLA should apply to.
2. If needed, select multiple departments.

3.2 Define the Rule Logic (Scope)

Decide how broadly the policy applies. You can target either:

• The entire department — every ticket in the selected department, or
• A specific category — only tickets in a chosen category.

If you select Specific Category:

1. Choose the category the SLA should apply to.
2. Choose the subcategory to narrow it further.

3.3 Add Optional Attribute Rules

You can refine the scope further with attribute-based conditions:

1. Click Add in the rules section.
2. Select the attribute for the rule (for example, Gender).
3. Select the value for the attribute (for example, Male).

With an attribute rule in place, the SLA applies only when these conditions are met. For this demo, cancel the rule configuration so the policy stays simple.

How matching works: When a ticket is created, the system picks the most specific matching policy first. The order of precedence is: a category-specific rule, then a department-wide attribute rule, then a plain department fallback. Attribute rules are evaluated as an "OR of AND" set — any rule group can match, and within a group every condition must be true.

3.4 Restrict to New Tickets (Optional)

Enable Only for new tickets if this SLA should apply only to newly created tickets and never affect tickets that already exist.

Why this matters: With this option off (the default), updating a ticket — such as changing its category or priority — can re-evaluate the policy and reset the SLA timer. Turning it on keeps the SLA fixed from the moment of creation, which prevents timers from "jumping" in complex ticket lifecycles.

When ready, click Next to continue.

---

Step 4 — Configure Assignment Rules and Approvals

This step defines who owns tickets under this SLA and how comments are approved.

4.1 Choose the Assignee

Tickets under this SLA can be assigned to:

• Individual users — direct assignment to one or more named people.
• User groups — a group, with tickets distributed among its members.
• A relationship — resolved from the requester's profile, such as Manager, HR, or VP.

For this example, select a group as the assignee.

4.2 Set the Ticket Distribution Rule

The distribution rule decides how tickets are shared among the selected assignees. Choose the type that fits your team:

• Round Robin — cycles through members based on past assignment counts.
• Round Robin (by active ticket count) — a variant that also weighs each agent's current open load.
• Sequential — cycles through members in a fixed order.
• Minimal Load — assigns to whoever has the fewest open tickets.
• Leave Unassigned — sets the group but leaves the individual owner blank.
• Any Group User — picks any available member at random.

4.3 Set the Default Priority

Choose the default priority applied to matching tickets (for this example, keep it Low).

4.4 Add Watchers (Optional)

Add watchers if certain people should be notified about tickets under this SLA without owning them. Add as many as needed.

4.5 Configure Comment Approvals (Optional)

To require approval before comments are posted on tickets under this SLA:

1. Add a comment approver.
2. Set the approver to a single user (for example, Abhishek Pal), so that any comment must be approved by that person, or
3. Set the approver to a user group, so any member of the group can approve.

For this demo, keep the approver as a single user.

When finished with assignments and approvals, click Next.

---

Step 5 — Define Escalation Rules

Escalations decide what happens when a ticket misses its response or resolution targets. You can configure both kinds, each with multiple levels.

Good to know: You can define up to five escalation levels for response and five for resolution. If you set a priority (such as Urgent) at a given level, it must also be set on every level before it — you cannot skip a priority partway through the chain.

5.1 Response Escalations

These apply when the first-response time is missed.

1. For Level 1, choose the person the ticket escalates to (for example, Abhishek Tahil).
2. Set the escalation time separately for each priority. For example:

• Urgent tickets escalate within 1 hour
• High priority tickets escalate within 2 hours
• Medium priority tickets escalate within 3 hours
• Low priority tickets escalate within 4 hours

Optionally, use the checkbox to apply these rules only for the first response from the assignee, so subsequent responses are not tracked for escalation.

5.2 Resolution Escalations

These apply when a ticket is not closed within the target time.

1. Open the resolution escalation section.
2. Define the rules and targets the same way as response escalations — choose who to escalate to and set the time for each priority.

Tip: Escalation timers respect your department's business hours and holiday calendar, so a target of "2 hours" counts working time, not wall-clock time.

---

Step 6 — Create and Activate the SLA

1. When all configurations are complete, click Create to save the SLA.
2. If any required field is missing (for example, an unselected user), the system prompts you. Fill in the required field.
3. Click Create again to finalize.

The policy is now saved and appears in the Active list.

Editing a Policy

You can edit an existing SLA policy in either of two ways:

• From the UI — open the SLA policy and update the required details.
• Through bulk upload — add a row to the upload file with the policy's exact SLA name and the updated details, then upload it. The SLA name is the unique identifier, so the matching policy is updated. See Part 2 for the upload flow.

Deactivating a Policy

To switch a policy off without deleting it:

1. Select the SLA policy.
2. Click Deactivate.

The policy moves to the Inactive tab, where you can review it at any time. Every create, update, enable, and disable action is recorded in the audit log for traceability.

Note: Removing or deactivating an SLA policy is only possible from the UI. It cannot be done through the bulk upload file.

---

Quick Reference: The Flow at a Glance

1. Access — Settings → SLA Policy V2.
2. Create & name — add a name and optional description.
3. Scope — pick department(s), choose entire department or a specific category, add optional attribute rules, and optionally limit to new tickets.
4. Assignment & approvals — set assignee, distribution rule, default priority, watchers, and comment approver.
5. Escalations — define response and resolution escalation levels and per-priority times.
6. Create & activate — save the policy; it goes live in the Active list. Edit it from the UI or via bulk upload. Deactivate any time (UI only) to move it to Inactive.

---

Part 2 — Bulk Uploading SLA Policies

This part explains how to bulk upload SLA policies using the SLA Policy V2 interface: how to import a CSV, validate it for errors, correct issues, and add only new SLAs without affecting the ones you already have.

Before You Begin

• You need an admin account, the same as for creating a single policy.
• Your data comes from a CSV file, with one SLA policy per row.
• The import is a two-phase flow: first Review (validate) the file, then Import (commit). Nothing is saved until you import.
• V2 appends, it does not replace. Uploading a CSV adds the new policies to your existing list — it does not wipe and re-create everything as the older version did. This means you can upload a file containing only your new policies.
• The SLA name is the unique identifier. If a row's SLA name matches an existing policy, that policy is updated with the row's details. If the name is new, the row is added as a new policy.
• Removing or deactivating a policy is UI-only. Leaving a policy out of the file, or removing its row, does not remove or deactivate it.

What gets validated: On review, the system checks each row for integrity before anything is saved — a unique policy name, a valid department, at least one assignee, and a complete escalation definition (an escalation level with a time must also name who to escalate to). Names for departments, categories, and groups are matched and converted to internal IDs during import.

---

Step 1 — Access the SLA Policy V2 Settings

1. Log in with an admin account.
2. Go to Settings.
3. Navigate to SLA Policy V2.

---

Step 2 — Open the Bulk Import Option

In the SLA Policy V2 screen, click Bulk Import at the top-right corner.

---

Step 3 — Select the CSV File to Upload

1. Click to select a CSV file for bulk import.
2. Choose the relevant CSV file from your system.
3. Click Open.

---

Step 4 — Review the Uploaded CSV for Errors

After selecting the file, use the Review option to validate the data before importing.

If there are problems, the system flags that the import contains errors and shows the number of rows affected.

1. Click the exclamation icon on any flagged row to view its detailed error messages.
2. Read the specific errors. A single row can have several. Common examples:

• Column X, escalation level one has an escalation time but no user group or relationship to escalate to.
• Duplicate SLA name found (for example, in rows three and four).
• Department is missing.
• At least one assignee email must be present.

3. Repeat the review for other flagged rows as needed.

Tip: All error details are shown directly in the UI, row by row, so you can compile the full list of fixes before going back to your CSV.

---

Step 5 — Correct the CSV and Re-upload

1. Open your CSV file locally.
2. Correct all the flagged errors — for example, add missing departments, fix duplicate names, and specify escalation targets for every level that has a time.
3. Save the file.
4. In the Bulk Import screen, use the Re-upload option to upload the corrected CSV.
5. Select the corrected file and click Open.
6. Click Review again to validate the updated file.
7. Confirm that the file now validates with no errors.

---

Step 6 — Understand the V2 Behavior for Existing SLAs

In SLA Policy V2 you no longer need to re-upload all existing SLAs.

• The older bulk upload replaced the entire list on every upload.
• V2 instead appends the new SLAs from your CSV without affecting policies that are already present.

So you can upload a CSV containing only your newly created SLAs, and they are added to the existing list.

To edit an existing SLA through the upload, include a row with its exact SLA name and the updated details. Because the SLA name is the unique identifier, the matching policy is updated rather than duplicated. Policies not included in the file stay unchanged.

To remove or deactivate an SLA, use the UI (see Step 8). This cannot be done through the file.

Why this matters: Appending (rather than replacing) means a small, targeted upload is safe — there's no risk of accidentally removing live policies that weren't included in the file.

---

Step 7 — Import the Validated SLAs

Once the review shows no errors, click Import to finalize the bulk upload.

The new SLAs are appended to the existing list, and their status shows as Active. Any rows that matched an existing SLA name update that policy.

---

Step 8 — Deactivate SLAs if Needed

If you need to switch off any of the newly added (or existing) policies:

1. Find the relevant SLA in the list.
2. Click Deactivate for that policy.

It moves to the Inactive tab, the same as a deactivated single policy in Part 1.

Note: Removing or deactivating an SLA is only possible from the UI, not through the bulk upload file.

---

Quick Reference: The Bulk Upload Flow at a Glance

1. Access — Settings → SLA Policy V2.
2. Bulk Import — open the option at the top-right.
3. Select CSV — choose your file and open it.
4. Review — validate; open the exclamation icon on flagged rows to read errors.
5. Fix & re-upload — correct the CSV, re-upload, and review again until clean.
6. Import — commit the validated file; new policies append as Active, and rows matching an existing SLA name update that policy.
7. Deactivate (optional) — switch off any policy from the UI to move it to Inactive.

---

How SLA is calculated in Helpdesk

A Service Level Agreement (SLA) defines how quickly the support team is expected to respond to and resolve a ticket.

Helpdesk calculates SLA deadlines using the ticket's applicable policy, priority, working days, working hours, holiday calendar, and timezone. An SLA of 4 hours does not necessarily mean 4 continuous hours after ticket creation—it means 4 eligible working hours.

---

1. Response SLA and resolution SLA

Helpdesk supports two separate targets:

These targets run separately. Responding to a ticket does not, by itself, complete its resolution SLA.

Example: A ticket may require a response within 2 working hours and resolution within 8 working hours.

---

2. How the applicable target is selected

Helpdesk selects an active SLA policy based on the ticket's department, category, subcategory, and any configured attribute conditions. More specific matching rules take precedence over general department-wide rules.

The ticket's priority determines the response and resolution durations within that policy. If no applicable policy supplies escalation settings, configured default ticket settings may be used.

The calculation can be understood as:

SLA deadline = starting time + target duration, counted only through eligible working periods and adjusted for qualifying pauses.

---

3. Working days, working hours, holidays, and timezone

---

4. Worked examples: working hours and holidays

For these examples, assume:

Case A: Ticket created during working hours

A ticket is created on Monday at 10:00 AM, with a 4-hour SLA.

Four working hours are available that day.

✅ Deadline: Monday at 2:00 PM.

Case B: Ticket created shortly before closing

A ticket is created on Monday at 4:00 PM, with a 4-hour SLA.

One hour counts on Monday. The remaining three hours count from Tuesday at 9:00 AM.

✅ Deadline: approximately Tuesday at noon.

Case C: Ticket created before opening

A ticket is created on Monday at 7:00 AM, with a 2-hour SLA.

The clock starts counting at 9:00 AM, when working hours begin.

✅ Deadline: Monday at 11:00 AM.

Case D: Ticket created after closing

A ticket is created on Monday at 7:00 PM, with a 2-hour SLA.

No time counts on Monday evening. Counting starts Tuesday at 9:00 AM.

✅ Deadline: Tuesday at 11:00 AM.

Case E: SLA spans a weekend

A ticket is created on Friday at 4:00 PM, with a 4-hour SLA.

One hour counts on Friday. Saturday and Sunday do not count. The remaining three hours count on Monday.

✅ Deadline: approximately Monday at noon.

Case F: Monday is also a holiday

Use the same Friday ticket, but mark Monday as a holiday.

One hour counts on Friday. The weekend and Monday's holiday are skipped. The remaining three hours count on Tuesday.

✅ Deadline: approximately Tuesday at noon.

Case G: Ticket created on a holiday

A ticket is created on a Monday holiday at 10:00 AM, with a 2-hour SLA.

No time counts on the holiday. If Tuesday is the next working day, counting begins Tuesday at 9:00 AM.

✅ Deadline: Tuesday at 11:00 AM.

Case H: SLA spans multiple working days

A ticket is created on Monday at 10:00 AM, with a 10-hour resolution SLA.

Seven hours count on Monday. The remaining three hours count on Tuesday.

✅ Deadline: approximately Tuesday at noon.

---

5. What happens when the ticket is waiting on someone?

In addition to non-working periods, Helpdesk supports explicit SLA pauses.

The clock can pause when:

When the ticket resumes, Helpdesk calculates the working time spent paused and extends outstanding SLA deadlines by that amount, using the same working calendar.

Example: Pause during the working day

A ticket is created Monday at 10:00 AM, with a 4-hour resolution SLA. Its original deadline is 2:00 PM.

At 11:00 AM, it moves to Pending on User. The requester responds at 1:00 PM, and the ticket resumes.

The ticket was paused for two working hours.

✅ Revised deadline: Monday at 4:00 PM.

Example: Pause across a weekend

A ticket pauses Friday at 4:00 PM and resumes Monday at 10:00 AM.

Only two working hours are counted as paused: Friday 4:00–5:00 PM and Monday 9:00–10:00 AM.

---

6. Important cases to keep in mind

• Ticket updates can affect deadlines: Changes such as category or priority updates can trigger SLA recalculation. Whether the original timing is retained or the timer resets depends on configuration.
• Escalation levels are configurable: A ticket can have multiple response and resolution escalation levels. Later levels can be calculated relative to the preceding level or the retained starting point, depending on settings.
• Warnings are different from breaches: An impending-breach notification is an early warning, not the actual SLA deadline. Its lead time is currently subtracted in ordinary elapsed hours, so a warning can fall outside working hours.
• Closing stops further escalation: Tickets in a closed-type status are not eligible for standard SLA escalation.

---

Summary

Helpdesk SLA measures eligible support time, rather than simply the calendar time since a ticket was raised. To understand a deadline, check the applicable target, department working hours, working days, holidays, timezone, and any paused periods. Those settings explain why two tickets with the same "4-hour SLA" can have very different calendar deadlines.