Ticket templates

Create templates for recurring tickets (e.g.: deploy, client onboarding, standard support): title, description, type, item checklist. Opening a ticket from a template fills everything at once.

Which checklists are ready-made when a request is opened. A template is a list of steps tied to a request type — the way to make sure no one forgets the step only the most experienced person remembers.

Installation, support ticket and implementation project require different steps. Tie each template to the corresponding request type: then the person opening it doesn't need to choose any checklist — it already comes right.

The list runs on the platform's standard engine: it exports the entire set in Excel, PDF and CSV, keeps saved views per user, lets you choose the visible columns per screen and keeps the trash — add ?excluidas=1 to the URL to see and recover deleted templates. Search by ?q=text and filtering by ?fd_=value also work directly in the URL, which lets you share by link a slice like "the active templates of type bug".

The default title and default description are the text the request is born with when someone opens it from this template — the creator can adjust it, but starts from a text that already asks for the right information. Use the default description as a small form: "Environment: / Steps to reproduce: / Expected result:" saves the second round of questions that every poorly opened request causes. The template name is internal, for whoever picks it from the list; the default title is what the requester sees.

Besides the text, the template defines the classification the request is born with: the request type, the priority and the severity. This matters more than it seems — they are exactly the three values that choose the request's SLA rule, so a template with the wrong priority creates wrong deadline commitments in series. Model the classification for the typical case of that work and let the exceptional be adjusted by hand by whoever opens it.

The template's items are copied to the request at the moment it is created. Changing the template later does NOT change requests already open — they continue with the checklist they received, which preserves the history of who completed what.

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 template can carry items — ordered steps that become the script/checklist of the request created from it: "collect logs", "reproduce in staging", "validate with the customer". It is the difference between a template that only saves typing and one that standardizes the WORK: with the items, every request of that type is born knowing the path. Remember that the template is applied on opening and becomes a copy: changing the items here applies to the next requests, it does not alter those already created.

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.

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

This is the screen that answers that question. You also get here through Ctrl+K by searching for: ticket, support, request, incident, help desk, service.