Ticket automations

Configure triggers (creation, status change, SLA breaching...) and automatic actions (assign owner, change priority, notify). The scanner runs the rules periodically.

"When this, do that" rules on requests: assign, notify, change status. Automation that triggers in cascade is the real risk of this screen — test with one case before turning it on for everyone.

The list runs on the platform's standard engine: export to Excel, PDF and CSV of the entire set, views saved per user for the filter combinations you repeat, column selection per screen and a recycle bin for deleted items (?excluidas=1 in the URL). Searching with ?q=text and filtering with ?fd_=value also work directly in the URL — useful for bookmarking "the active automations" and checking at a glance what is turned on in the environment.

The trigger is the event that wakes up the automation. The other condition fields narrow WHEN it applies: the request type restricts it to one type, source/target status tie the rule to a specific transition, and source priority filters by priority. A blank condition means "applies to any" — an automation with no condition at all runs for every event of the trigger, which is rarely the intention. The more specific the conditions, the more predictable the effect.

The Action field defines the automation's effect, and the target fields complete it: target user and target employee say whom the action points to (an assignment, for example), the action parameter carries the value the action needs, and the message is the text used when the action notifies someone. Fill in only what the chosen action uses — a target that makes no sense for the action is ignored, and the automation seems to "not work" when in fact the wrong field was filled in.

A wrong automation doesn't fail once — it fails at scale: it runs for EVERY request that matches the trigger and the conditions, and a wrong target reassigns or notifies dozens of requests before anyone notices. Build the automation DISABLED, check the trigger, the conditions (type, source/target status, priority) and the action with its target, and only then turn on the Active switch. To investigate strange behavior, disable it instead of deleting it: the configuration stays preserved for analysis.

Every automation in the list has the same anatomy: a TRIGGER (the event that wakes it up), CONDITIONS that narrow when it applies (demand type, source and target status, source priority) and an ACTION with a target (user or employee), parameter and notification message. Order defines the sequence when several automations respond to the same event, and Active is the switch. Reading the list with this in mind helps to find overlaps: two automations with the same trigger and similar conditions will fight over the same demand.

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.

When more than one automation responds to the same event, the Order field defines the sequence in which they are evaluated — lower numbers come first. And the Active switch is the on/off switch: deactivating keeps the whole configuration without running it, which is the safe way to take an automation out of the picture to investigate strange behavior (instead of deleting it and losing the recipe). It also works as a draft: build the automation deactivated, review the conditions and only then turn it on.

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.

Check in this order: (1) is the Active switch on? A deactivated automation never runs, by definition. (2) Is the trigger really the event that happened? (3) Did ALL the conditions match — demand type, source status, target status, source priority? A single unmatched condition is enough for the automation to stay quiet, and that is not an error: it is the filter working. (4) If there are several automations on the same event, look at the Order — another one may have acted first. The most common case is (3): a condition nobody remembers exists.

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

Choose the client in the automation's "Client" field. The rule then applies only to that client's requests, including those coming through the portal and by email, and it runs after the request has inherited from the contract: whatever the rule does prevails. To send that client's requests to someone else, use the "Assign to employee" action. A creation automation with no client chosen also applies to these requests and, since it runs after the inheritance, whatever it does also prevails.

On every status change of the request, whether it comes from the record, the list, the Kanban, My Agenda, the timer, pause and resume or the integration. "On creation" and "on priority change" automations do not run when someone only moves the request. An automation that changes the status also follows the type workflow and does not trigger the automations again; if the workflow does not allow the change, the request history says why.

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.