> For the complete documentation index, see [llms.txt](https://docs.harmony.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.harmony.io/settings/configuring-automation-and-sla.md).

# Configuring Automation and SLA

{% hint style="info" %}
**Paths:** Automation: `/settings/desks/$deskId/automation` · SLA: `/settings/desks/$deskId/sla`
{% endhint %}

### Configuring Automation Rules

Automation rules control how tickets behave without manual action: who gets assigned, when status changes, and when tickets close. Configure these per desk from **Settings** → **Desks** → *desk* → **Automation**.

#### Understanding Automation Rules

Automation includes:

* **Ticket assignment** - How unassigned tickets are routed to agents (round-robin, least-loaded, first responder, or fixed)
* **Status management** - Automatic status changes when reporter or agent replies
* **Auto-close** - Closing tickets after inactivity or when linked tickets resolve
* **Surveys** - Satisfaction feedback collection after resolution

#### Creating and Editing Automation

Automation is configured per desk. Open the **Automation** tab for the desk. Each section has its own enable/disable and configuration. Changes save immediately when you update settings.

![Automation tab with ticket assignment (round-robin, least-loaded, etc.)](/files/j2IXYsm85QLhdfk0FV7U)

***

#### Configuring Auto-Assignment

You can automatically assign incoming tickets to agents within a desk, eliminating the need for manual triage. Enable auto-assignment from the **Automation** tab in desk settings and choose an assignment method from the dropdown. Each method in the dropdown includes a description to help you understand how tickets are distributed before making a selection.

**Assignment methods**

* **Round-robin** - Rotates new tickets evenly through available agents in a consistent order (selected by default). The rotation pointer advances through the full agent list, preserving fairness over time.
* **Least-loaded** - Assigns each new ticket to the agent with the fewest currently open tickets. Only available agents are considered when calculating load.
* **Fixed** - Always routes tickets to one specific agent you designate.
* **First responder** - Automatically assigns an unassigned ticket to the first agent who sends a public reply (via Slack, Teams, or the ticket chat). This rule only fires when the ticket has no assignee, is not yet resolved or closed, and the responder is a desk agent.

For round-robin and least-loaded methods, you can control which agents are included in the assignment pool.

**Skipping out-of-office agents**

When Round Robin or Least Loaded is selected, a **Skip members who are currently out of office** checkbox appears in your auto-assignment settings. When enabled:

* **Round Robin** - The rotation pointer continues to advance through the full agent list, preserving fairness. Out-of-office agents are simply passed over without resetting the rotation order.
* **Least Loaded** - Only agents who are currently available are considered when calculating workload and making assignments.

This ensures work lands with someone who is actually available without disrupting the overall assignment logic.

**Automatic status update on assignment**

When an agent is automatically assigned to a ticket after the first-responder rule fires, the ticket status automatically moves from **Open** to **In Progress**. This ensures your queue reflects real-time activity without requiring manual status updates. The status change only occurs when the ticket is currently **Open** - tickets already in another status are not affected. SLA time-to-response tracking begins as soon as the status transitions to In Progress.

**Assignment reliability**

Auto-assignment includes retry logic for the membership checks that determine which agents are eligible to handle incoming tickets. If a brief or transient issue occurs in the underlying access management service, the system automatically re-attempts these checks with exponential backoff - resolving the vast majority of transient failures without any impact to your team's routing or first-responder assignments.

***

#### Configuring Auto-Close Settings

Auto-close is **disabled by default** and must be explicitly enabled per desk. When enabled, tickets in a resolved state are moved to "Closed" after the configured inactivity period has elapsed. Each auto-closure is recorded as a system event in the ticket's activity log, noting the status transition. Agents can still manually reopen tickets if needed.

**Inactivity-based closure**

* **Resolved tickets** - Close after 1-365 days of reporter inactivity (no reply from reporter).
* **Pending tickets** - Close after 1-365 days of reporter inactivity.
* **Reminder** - Optional reminder 1-200 hours before closing to prompt reporter action.

Auto-close timers respect your team's business schedule. Only time within your defined business hours and working days counts toward the auto-close threshold, so tickets are not closed during off-hours, weekends, or holidays. Calendar holidays configured for the desk also pause the timer on non-working days.

**Pre-closure reminders for reporters**

Before a ticket is auto-closed, reporters can automatically receive a personal Slack or Microsoft Teams notification containing the ticket name, current status, and a direct link to the Self-Service Portal. This gives them a clear window to respond before the ticket closes. Configure this option under **Desk Settings** → **Automation**.

**Reopen on comment**

You can configure resolved tickets to reopen automatically when a reporter adds a comment via Slack, Teams, or the Self-Service Portal. This lets reporters reopen their own tickets simply by replying, without needing to contact support directly. Configure this option under **Desk Settings** → **Automation**.

**Linked tickets**

When a parent ticket is resolved, downstream linked tickets can auto-close based on:

* **Link types** - Depends on, Blocked by, Duplicate of
* **Eligible statuses** - Open, In Progress, Pending reporter, Pending approval, Pending internal team, Pending third party, Resolved

**Mandatory close comment**

Require an internal comment when closing a ticket. When enabled, agents must add a comment before closing.

![Automation tab with inactivity-based closure options](/files/EW5iL8ffGDw9ncEqt0vY)

***

#### Setting Up Status Management

**Comment-driven status**

When status management automation is enabled, ticket statuses update automatically based on who replied most recently, eliminating the need for agents to manually move tickets between states:

* **Reporter (employee) replies** - The ticket automatically moves from "Pending Reporter" back to **In Progress**, signalling that the ball is in the agent's court.
* **Agent replies** - The ticket automatically moves to **Pending Reporter**, indicating the team is waiting on the reporter.

Enable or disable this behavior in the **Status management** section of the Automation tab.

**Approval workflow outcomes**

You can now configure different ticket status transitions depending on the outcome of an approval step in your workflows. Each outcome - approved, rejected, or any other configured result - can automatically move the ticket to a distinct status. This gives your team finer control over how tickets progress through your support process after human review decisions, rather than applying a single status update regardless of outcome.

#### Understanding Status Transitions

Status automation uses these transitions:

* **Pending Reporter** → **In Progress** - When the reporter replies
* **In Progress** (or similar) → **Pending Reporter** - When an agent replies

Other status changes (e.g., Resolved, Closed) are manual or driven by workflows and approvals. Approval workflow outcomes can be mapped to custom statuses as described above.

#### Configuring Status Automation

Use the **Status management** toggle to turn comment-driven status on or off. No additional configuration is needed for the standard transitions; they are fixed as described above. For approval-outcome-based status changes, configure the desired status per outcome within your approval workflow settings.

***

#### Configuring Survey Settings (Feedback)

* **Enable/disable** - Turn satisfaction surveys on or off independently for each desk (enabled by default).
* **Delay** - Set a custom delay for when the survey is sent after ticket resolution.
* **Reminder** - If the reporter has not completed the survey within 1-200 hours of resolution, send an optional reminder.

Surveys are sent to service requesters via Slack or Microsoft Teams direct message after a ticket is resolved. Each survey asks "How would you rate the service you received?" with a 1-5 scale and includes the ticket ID, status, and a link to the self-service portal for context. Once a requester submits their rating, the survey is marked complete and cannot be resubmitted.

**Survey rating order**

Rating options in Slack and Teams notifications appear from positive to negative - starting with **Excellent** and ending with **Very bad** - following standard UI/UX conventions that make it easier and more intuitive for end users to respond.

**Low-rating follow-up**

When a user rates their experience as **Average (3)**, **Bad (2)**, or **Very Bad (1)**, they are prompted with "What could we have done better?" and must provide a response before submitting. This gives your team richer context on negative feedback. Ratings of **Good (4)** and **Excellent (5)** submit immediately, unchanged. This applies across both Slack and Microsoft Teams.

**Bulk survey management**

You can perform bulk actions on surveys, making it faster to manage multiple surveys at once. Select multiple surveys and apply actions across all of them in a single operation - especially useful for teams managing large volumes of surveys or needing to make consistent changes at scale.

Results are used for reporting and compliance.

***

### Configuring SLA Policies

SLA (Service Level Agreement) policies define response and resolution targets by ticket priority. Configure from **Settings** → **Desks** → *desk* → **SLA**.

#### Understanding SLA Policies

An SLA policy sets:

* **Response time** - How quickly an agent must first respond (e.g., acknowledge the ticket)
* **Resolution time** - How quickly the ticket must be resolved
* **Working hours** - When the SLA clock runs (24/7 or custom schedule)
* **Warning thresholds** - When to alert before breaching (e.g., 80% of target elapsed)

#### Setting Up SLA Policies

1. Open the desk → **SLA** tab.

![SLA tab with response and resolution targets by priority](/files/DNWwWEJVKwrM2LR2F62S)

2. Enable SLA for the desk (if disabled).
3. Set response and resolution times for each priority.
4. Configure working hours (or use 24/7).
5. Optionally adjust warning percentages for breach alerts.

#### Configuring Priority-Based SLAs

Each priority has its own targets:

| Priority   | Typical default (response / resolution) |
| ---------- | --------------------------------------- |
| **Urgent** | 12 hours / 24 hours                     |
| **High**   | 24 hours / 48 hours                     |
| **Medium** | 4 hours / 24 hours                      |
| **Low**    | 8 hours / 48 hours                      |

#### Configuring SLA Targets by Priority Level

For each priority (Urgent, High, Medium, Low), set:

* **Response time** - First response target
* **Resolution time** - Full resolution target

Response time must be less than or equal to resolution time. Both use the same time options.

#### Setting Response Time Targets

Available options: 15 minutes, 30 minutes, 1 hour, 2 hours, 4 hours, 8 hours, 12 hours, 24 hours, 48 hours, 72 hours, 1 week.

Response time is the deadline for an agent to first respond (e.g., add a comment or change status).

#### Setting Resolution Time Targets

Same options as response time: 15 minutes through 1 week. Resolution time must be at least as long as the response time for that priority. It defines when the ticket should be resolved (e.g., closed or marked resolved).

#### Understanding SLA Working Hours

SLA timers run only during **working hours** unless you use 24/7. Working hours are configured per desk (main) or per team. Outside working hours, the SLA clock pauses. Holidays (from the holiday calendar) also pause the clock.

**SLA timers and Pending status**

SLA timers automatically pause whenever a ticket enters the **Pending** status. Time spent waiting on a customer or third party no longer counts against SLA targets, so your metrics accurately reflect only the time your team is actively working on an issue. Once the ticket moves out of Pending, the SLA timer resumes from where it left off.

**Holiday calendars**

You can configure holiday calendars for your desks to ensure SLA timers automatically pause on public holidays and custom time-off days. This keeps response and resolution targets accurate without requiring manual adjustments around holidays.

* **Import official holiday calendars** by country - each entry includes the holiday name, date, and location, with data stored up to 5 years in advance.
* **Add custom holidays or team-off days** by selecting a date from the calendar and entering an event name, useful for local observances or company-wide days off.
* **Remove calendar entries** at any time to adjust your schedule.

#### Setting Up 24/7 SLA Tracking

Select **24 × 7 support** in the Working hours section to run SLA timers continuously. No pauses for nights or weekends. Use this when your team provides around-the-clock support.

#### Understanding SLA Breach Handling

**Breach detection**

A breach occurs when the response or resolution deadline passes without the required action. Status values: *active* (in progress), *breached* (deadline passed), *completed* (target met).

**Display**

* **Ticket preview** - Response and resolution SLA shown with color: red (breached), green (active/met), gray (completed). Each ticket displays both **Time to First Response** and **Time to Resolution** SLA indicators with clear status states (on track, at risk, or breached).
* **Tickets table** - A dedicated **Time-to-Resolution** column is available, sortable so you can quickly prioritize tickets at risk of breaching their SLA. The TTR cell shows SLA status and date; breached tickets have a red icon.

**Notifications**

Configure **SLA breach** as a notification type in the desk's Notifications settings. When a ticket breaches, the event is sent to the configured destinations (e.g., Slack, Teams).

**Dashboard and reporting**

* SLA Breached Tickets widget shows breach count.
* SLA compliance metrics (e.g., breach count, compliance rate) are available for dashboards and reports.

***

### Related Resources

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Service Desks &#x26; Teams</strong></td><td>Desk structure, teams, and working hours</td><td><a href="https://github.com/harmonyso/public-docs/tree/main/guides/managing-service-desks-and-teams/README.md">https://github.com/harmonyso/public-docs/tree/main/guides/managing-service-desks-and-teams/README.md</a></td></tr><tr><td><strong>Ticket Settings</strong></td><td>Custom fields, tags, canned responses, notifications</td><td><a href="https://github.com/harmonyso/public-docs/tree/main/guides/managing-ticket-settings/README.md">https://github.com/harmonyso/public-docs/tree/main/guides/managing-ticket-settings/README.md</a></td></tr><tr><td><strong>Service Desk &#x26; Tickets</strong></td><td>Create and manage tickets that SLAs apply to</td><td><a href="https://github.com/harmonyso/public-docs/tree/main/guides/understanding-service-desk-and-managing-tickets/README.md">https://github.com/harmonyso/public-docs/tree/main/guides/understanding-service-desk-and-managing-tickets/README.md</a></td></tr><tr><td><strong>Service Desk Metrics</strong></td><td>Analyze SLA compliance and breach trends</td><td><a href="https://github.com/harmonyso/public-docs/tree/main/guides/analyzing-service-desk-metrics/README.md">https://github.com/harmonyso/public-docs/tree/main/guides/analyzing-service-desk-metrics/README.md</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.harmony.io/settings/configuring-automation-and-sla.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.