Regra de SLA

Each rule is a combination: request type + priority + severity. When a request is created, the system looks for the rule that matches those three values of it and applies the deadlines of that line. That is why it is worth covering the combinations the operation really uses: a request whose trio matches no rule has no SLA calculated and its traffic light starts looking at the forecast date. The "Business hours" field of each rule defines whether the deadline counts only during working hours (8am–6pm, working days) or in continuous hours.

The rule carries two independent deadlines, in hours: "1st response" measures how long the customer can wait until someone gives the first sign of life on the request; "resolution" measures by when the problem needs to be solved. Both are calculated from the opening of the request, each with its own value — responding quickly does not extend the resolution deadline, and a service can meet one clock and breach the other. Leaving one of the two blank means not measuring that commitment for that combination.

Here you see and fix loose child records, one by one. In day-to-day work, however, the right thing is to create and edit them inside the parent record's form: that is where the business rules run (recalculated totals, validations, numbering, history). Editing directly here is useful for auditing and for correcting a specific case — but it can leave the parent record with an outdated total, and that raises no error on screen.

Each rule states the deadline for a combination (priority, type, channel). It is what makes the ticket's clock run — and it is the deadline here that triggers the automatic follow-up when it is breached.

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.

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?".