SLA policies

Register policies with rules by priority/type: first-response time and resolution time. The ticket inherits the applicable policy and the dashboard measures compliance.

The deadline promised by priority, and what happens when it is about to expire. The clock follows the registered CALENDAR: without a correct calendar and holidays, the SLA counts hours nobody worked and flags delays that didn't happen.

Here you create and maintain an SLA policy: name, description and the active switch. The policy is the shell — the real deadlines live in its rules, which combine request type, priority and severity with the first response and resolution hours. An inactive policy is not applied to any new request.

The SLA's "paused clock" is business hours: when the policy's rule is marked with "Business hours", the deadline only counts from 8am to 6pm on business days — nights, weekends and national holidays don't run against the clock. A critical ticket opened Friday at 5pm with a 10-business-hour deadline expires Monday at 5pm, not Saturday morning. Rules without this mark run in continuous hours, without any pause — the right choice only for contracted 24×7 support.

SLA isn't mandatory for everything: when a request finds no rule matching its type, priority and severity, the system doesn't invent a deadline — that request's traffic light starts looking at the forecast date filled in on it (overdue = red, due today = orange, a few days left = attention). This explains why two similar requests can have traffic lights calculated in different ways: one matched an SLA rule, the other is being read by its forecast.

When you save a view with the Views button, it stores four things: the search text, the applied filters, which columns appear (and in what order) and which column the list is sorted by. Applying the view restores everything at once — including resetting the sort and the page you were on, so the result is exactly what the view describes. Views saved before this version remain valid: whatever they didn't store simply doesn't change when applied.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

The name and description on this screen don't define any deadline: what defines them are the policy's rules, and each rule matches a combination of request type, priority and severity with two independent clocks — hours until first response and hours until resolution. When a request is created, the system looks for the rule that matches its type, priority and severity and calculates both deadlines from the moment it was opened. A request with no matching rule has no calculated SLA — its status light then looks at the forecast date.

A rule marked "Business hours" counts the deadline only within working hours: 8 a.m. to 6 p.m., on business days — weekends and national holidays don't count. A 10-business-hour SLA opened on Friday at 5 p.m., for example, expires on Monday at 5 p.m., not on Saturday morning. Without the mark, the deadline runs in calendar hours, nights and Sundays included — appropriate for contracts with 24×7 support. The choice is per rule, so the same policy can have critical severity in calendar hours and the rest in business hours.

In the record's activity panel, each note has "Turn into request". The click creates a ticket with the note's text, who wrote it and the link to this record — nothing is retyped. Use it when the note is a request for action ("someone needs to review this"); the note stays where it was. The button only appears once the record has been saved; a read-only session (demo) doesn't create one.

Whoever has permission to view this screen in their access profile — usually whoever configures the service operation, since touching an SLA policy changes the promised deadline of every ticket that matches its rules. The grant is made on the Access screen by the account's administrators, and the contracted plan needs to include the module: profile and plan are independent locks.

The SLA status of a request with a rule has three colors: on time, ATTENTION when less than 4 hours remain until the resolution deadline, and OVERDUE when the deadline has passed. A resolved or closed request is judged by the date it was resolved: within the deadline it stays OK forever, outside it stays overdue forever — resolving later doesn't "clear" the violation. It is this judgment, request by request, that feeds the compliance rate shown on the Requests Dashboard.

Open the record and look at the Timeline on the right: it shows each change as "from one value to another", with the person and the date. When there are many changes, use the two filters at the top of the timeline — one by field, the other by person. The search runs in the database, so old changes show up just the same. You can also ask Tenkai: "who changed contract 482?".