---
title: SLA Control Refactoring
slug: pink/sla-control-refactoring
description: This document outlines changes made to the modeling and screens for parameterizing Service Level Agreement (SLA) time for tickets and problems. It includes information on the new table created for this purpose and the inclusion of update scripts. It also 
docTags: 
createdAt: 2022-11-11T14:56:27.000Z
---

The modeling and screens that parameterize the SLA time were modified, in the items that have the control of **Ticket** and **Problem**.

## Tables

The **acordoservicocontrato** table is no longer used to parameterize the SLA time of activities. The **tempoatendservicocontrato** table was created to define this relationship, which is now created by linking the **servicocontrato** directly to the **acordonivelservico** (Service time); that is, before an SLA is defined for an activity the service level agreement it must be defined for the activity in portfolio registration or maintenance screen.

## Automatic Loading

Update scripts were included in the system that will load data into the table **tempoatendservicocontrato**, at the time of updating and respecting existing relationships.

Therefore, after this update, the system must continue to apply the previously parameterized SLAs.

## Targets removal

The service time screen has been redesigned and changed to no longer define contract targets and activity for service time. This responsibility was passed to the **portfolio screen **and** portfolio maintenance.**

![](https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/W2tMdlFTCy7ix8222GJd4_image.png)

## Removal of the Global, Per customer, and Specific Concept

The concept of Global SLA, by customer and specific, no longer exists in the system. Now all are SLAs specific, defined directly in the portfolio of activities. The seasonal SLA concept remains, well as a definition of VIP priorities.

![](https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/WsBDVcL7I-2Ldz05toFC8_image.png)

## New Business Rule

It is possible to relate, only, a single service time (Service Level Agreement) main to an activity, however, as many times, of the seasonal type, are necessary.

## Portfolio Screen

The portfolio screen has been changed to record **servicocontrato** relationship with service agreements level of service, which can be applied to tickets, the choice of SLA will be in accordance with what has the highest priority, respecting the priority of the service level agreement, calculated by the impact and priority of the service time, the priority of the unit, the priority of the employee and the requester's group.

The time setting will be chosen from the highest priority.

The flow definition and service time components have changed position and type, now the flow definition is of the “**select**” type and the service time definition is in a table format, as this is what needs to be added records and not the flow that is only one per activity.







### Former Screen

![](https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/KvB5xBm1nrmDUTXWzni9Y_image.png)



### New Screen

![](https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/vb0zV6iKu6olQzrvaWQ_0_image.png)

## Portfolio Maintenance Screen

The possibility to define the SLA time for multiple activities was included, using the Portfolio Maintenance. Another important change is that we can now update information, in batches, from activities already related to the contract, the rules are as follows:

- When linking activities to the contract or contract to activities, the system will add new relationships and update the existing ones, with the information fed into the final step of linking, where the user can define the flow, service time, calendar, date of start…
- Only the information that is filled in in the final step of the link will be applied, one being record inclusion or update;
- If one or more activities are linked to the service contract, that is, performing an **insertion operation** in the database, if some **obligatory information is missing**, the operation **will not be completed** and the user will receive a message requesting them.

### New Maintenance Screen

![](https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/espXK1aIMqlMi2NOAQSrE_image.png)



### Time definition

![](https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/y7uXXSJjotQoT3k3F0uuQ_image.png)

## Non-altered Rules

- Priority calculation using or not parameter 104;
- VIP priority setting;
- Seasonality control;
- SLA definition algorithm for all modules – This code has been refactored, but without changing business rules;
- Definition of SLA per task;
- SLA compliance calculation.




Impacts


### Screens

- Ticket
- SmartPortal
- ExperienceCenter
- TemplateSolicitacao
- AcaoIncidenteRequisicao
- Problema

### Removal

The following methods have been removed:

- AcordoNivelServicoService().findANSSazonalByIdServicoContrato
- AcordoNivelServicoService().findANSIncReqProcByIdServicoContrato
- AcordoNivelServicoService().findANSCliente
- AcordoNivelServicoService().findANSGlobal
- AcordoNivelServicoService().getIdANSSazonal

## Apendix

For this knowledge, the SQL file with the script used to load the data to define the SLA is attached to the **Tasker-14847**.

## SQLs for database analysis

### Table that stores service and activity

```sql
select * from servico s
```

### Table that defines the nature of each record

```sql
select * from servicoautorelacionamento s2
idservico - Refere-se à atividade
idservicorelacionado - Refere-se ao servico de negócio
```

### Service/activity relationship with the contract

```sql
select * from servicocontrato
```



### Service time

```sql
select * from acordonivelservico a
```



### Former relationship

```sql
select * from acordonivelservicocontrato a
```

### New relationship

```sql
select * from tempoatendservicocontrato t
```