Item de template

Each template item has only two fields, and both matter: the description is the step itself — write it as an executable instruction ("collect environment logs", not "logs") — and the order defines the sequence in which the steps appear in the created request. The order is the script: think of it as the real sequence of the work, because that is the sequence in which the person handling it will check off the steps. Out-of-order items produce checklists the team learns to ignore.

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 item becomes a task (or checklist item) when a ticket is born from that template. Changing it here applies to the NEXT tickets; those already open keep the script they were born with.

The template is applied when the request is OPENED and what it generates becomes a copy belonging to the request: adding, removing or reordering items here applies to requests created FROM THEN ON — those already open continue with the script they received at birth. This is intentional: a request in the middle of handling cannot have its checklist swapped out from under the handler's feet. If a new step is urgent for requests in progress too, it needs to be added to them one by one, consciously.

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