Projected cash

Three flags define the role of each status within the flow: INITIAL is where the demand is born when it enters this workflow; FINAL declares the end of the cycle — it is what separates closed from in progress on the dashboards; and "Visible to customer" decides whether that state appears to the customer on the outside. A healthy flow has exactly one initial status and at least one final; and it is worth reviewing external visibility state by state — "under internal root cause analysis" may not be the message you want on the portal.

The Order field is not cosmetic: it defines the sequence of the statuses within the flow, and it is this sequence that the kanban board uses to draw the columns from left to right. Order them the way work really moves — triage before execution, execution before validation — so that the board tells the right story: on a well-ordered kanban, the card moves to the right, and any card moving "backward" stands out as the rework it is.

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 status is a column on the board and a possible state of the ticket. A status marked as final closes the ticket and stops the SLA clock — that is why creating a new final status changes how service time is measured.

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