# Service Level Agreement (SLA)

## Overview

In the Complaints Management, the SLA or Service Level Agreement specifies how long a grievance can remain in a specific status before it is automatically escalated to the next level (for example, assigned to a higher authority). DIGIT offers an auto-escalation mechanism that monitors each complaint’s workflow and advances it if no action is taken within the designated time.

This configuration ensures:

* Timely handling of complaints
* Less manual intervention
* Efficient and automated escalation

***

## Configure SLA

{% stepper %}
{% step %}

### Open the configuration file

Navigate to: [`data/pg/Workflow/AutoEscalation.json` ](https://github.com/egovernments/Citizen-Complaint-Resolution-System/blob/master/utilities/default-data-handler/src/main/resources/mdmsData/Workflow/Workflow.AutoEscalation.json) The SLA values are configured here.

Each entry in this file defines:

* Which business service (like PGR)
* Which workflow state (like PENDING)
* What action to perform when the SLA is breached
* The SLA duration in days
* And which Kafka topic the escalation event should be pushed to
  {% endstep %}

{% step %}

### Edit the configuration values (as needed)

Add one entry per state that requires auto-escalation. Fill in fields as shown in the sample configuration.

* Use a realistic SLA value (`stateSLA`) in **days**.
  * `1` = 1 day
  * `0.5` = 12 hours
  * `0.01` = \~15 minutes
    {% endstep %}
    {% endstepper %}

***

## Sample Configuration

#### 🔹 1. Escalate from PENDINGATLME State

```
{
  "businessService": "PGR",
  "module": "pgr-services",
  "state": "PENDINGATLME",
  "action": "FORWARD",
  "active": "true",
  "stateSLA": 3.0,
  "businessSLA": null,
  "topic": "pgr-auto-escalation"
}
```

* If a complaint is in the PENDINGATLME state for more than 3 days, and no action is taken.
* The system will automatically trigger the "FORWARD" action.
* This moves the complaint forward in the workflow (usually to the next responsible officer).
* The message is sent to the Kafka topic pgr-auto-escalation for processing.

#### 🔹 2. Escalate from PENDINGFORASSIGNMENT State

```
{
  "businessService": "PGR",
  "module": "pgr-services",
  "state": "PENDINGFORASSIGNMENT",
  "action": "ASSIGNEDBYAUTOESCALATION",
  "active": "true",
  "stateSLA": 3.0,
  "businessSLA": null,
  "topic": "pgr-auto-escalation"
}
```

* If a complaint is waiting for an assignee (PENDINGFORASSIGNMENT) for more 3 days,
* The system auto-assigns it using the "ASSIGNEDBYAUTOESCALATION" action.
* This ensures the complaint does not remain unassigned.

#### 🔹 3. Escalate from REJECTED State

```
{
  "businessService": "PGR",
  "module": "pgr-services",
  "state": "REJECTED",
  "action": "CANCEL",
  "active": "true",
  "stateSLA": 3.0,
  "businessSLA": null,
  "topic": "pgr-auto-escalation"
}
```

* If a complaint is in the REJECTED state for more than 3 days,
* It will be moved to a CANCELLED status automatically using the "CANCEL" action.
* This helps clean up rejected complaints that are not manually closed.

***

###  Key Parameters

<table><thead><tr><th width="206.09375">Parameters</th><th>Description</th></tr></thead><tbody><tr><td>businessService</td><td>The module this SLA applies to (PGR in this case)</td></tr><tr><td>state</td><td>The complaint's current workflow state</td></tr><tr><td>action</td><td>The next step the system will auto-trigger</td></tr><tr><td>stateSLA</td><td>Time in days before auto-escalation (e.g., 3.0 = 3 days)</td></tr><tr><td>topic</td><td>Kafka topic where the escalation event is published</td></tr><tr><td>active</td><td>Whether this escalation rule is currently active</td></tr></tbody></table>

***

### Example Use Case

Imagine a citizen raises a complaint about a streetlight not working:

* It lands in PENDINGATLME state.
* If no one takes action in 14 minutes, the system auto-forwards it to the next level.
* If it's stuck waiting for an assignment, it gets auto-assigned.
* If someone rejects it and doesn’t close it manually, it gets cancelled automatically.