Ticket workflows

Build flows: from each status, which statuses the ticket can move to. The kanban and the ticket screen obey these transitions.

Designs the statuses and the allowed transitions. A transition that does not exist is an impossible transition for the user — if someone complains "I can't move the request", this is the place to look, not the permission.

Here you create and maintain a request workflow: the name, the request type it applies to and the active flag. The flow itself — which statuses exist and along which paths the request moves between them — is built in the details of the record itself: the workflow statuses and the transitions, each with its own rules.

The list runs on the standard engine: export of the whole set to Excel, PDF and CSV, views saved per user, column choice per screen and a recycle bin for deleted items (?excluidas=1 in the URL). Search and filter work by URL — ?q=text and ?fd_=value —, which lets you share the exact slice by link ("the active workflows") instead of click-by-click instructions. The "?" button reopens this help and Ctrl+K finds any screen by name.

The flow design lives in two details of the record. The WORKFLOW STATUSES list the states the request can have, with the order, the initial mark (where it is born), the final mark (where it ends) and the visibility for the customer. The TRANSITIONS say from where to where it can go, with the action name and the requirements of each step: mandatory comment, approval, time logging and whether the customer can execute it. A status without an incoming transition is an unreachable state — the flow only works with both halves.

Removing a transition used in day-to-day work locks the team (a ticket "stuck" in a status). Prefer adjusting during low-usage hours and inform the team.

The Requests Kanban board is drawn from the workflows in this list: the columns are the statuses of the request type's flow. When no workflow is configured, the kanban doesn't invent columns — it shows a warning with a direct link to this screen. So, if someone on the team reports "the board is empty/has no columns", the diagnosis starts here: is there a workflow for the type? Is it active? Does the request use a type that has a flow?

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.

Each workflow points to a request type: it is the flow of that type — a bug can follow one path, a service request another. The kanban board is born from this link: the board's columns are the statuses of the type's workflow, and the kanban's workflow filter switches the set of columns displayed. If no flow is configured, the board warns you and points here. Deactivating a workflow takes the flow out of play while preserving the configuration — the reversible path when you want to redesign without losing the old design.

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