Predictability

Each status change can carry up to three locks, independent of each other: "Requires comment" forces whoever moves the demand to explain why — it is the memory of the decision; "Requires approval" makes the change conditional on sign-off from someone who can approve; and "Requires time entry" demands hours logged before moving forward — the classic lock before completing, so that work does not end without recorded cost. Use each lock where it pays its own toll: too much demand on a trivial change teaches the team to write "ok" just to get through.

The transition links a source status to a target one, and the "action name" is how this change presents itself to those who work: "Send to testing", "Return for adjustment", "Complete". Name it by the action verb, not by the arrival status — "Approve budget" communicates more than "Move to approved". The "Customer can" switch decides whether this action is also available to the customer; and the active switch takes the change off stage without deleting it, preserving the design in case the flow goes back.

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 transition authorizes a path between two statuses. What is NOT here is forbidden: that is how the flow prevents skipping a stage. If a user complains that they cannot move the ticket, the answer is almost always on this screen.

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