"Every bug needs a component" and "raise the quarterly access review every Monday" are the same kind of object in Trakr. Four scopes, two execution modes, eleven checks, a full field-condition system — and a dry run that changes nothing and tells nobody.
Scope, trigger, selection, checks, actions, notification. Six decisions, one form.
* and ?currentUser() in a rule's filterSelection happens first — by ticket scope, a TQL filter, an include-done flag and a cap on tickets per run, 500 by default. Whatever survives that gets checked.
Automation is easy to write and hard to trust. These are the reasons you can turn it on and go home.
When a rule sets a priority, that update does not fire the "updated" event for another rule to react to. The graph is flat, with no depth limit to tune and no runaway loop to discover at three in the morning.
Actions are ordered and applied individually, so one failure costs one action rather than aborting the run. An action applies once per finding, not once per run — the same open problem does not get acted on repeatedly just because the schedule ticked again.
The transition action goes through the project's own workflow engine. If the workflow says that move is not legal from this status, the automation records a failed action and moves on. It does not have a back door, because a back door would make the workflow a suggestion.
Auto-assign behaves the same way: on a project set to manual routing, it is reported as a failed action naming the reason, rather than silently doing nothing or inventing an assignee.
Per rule and ticket, Trakr tracks the finding, when it was first and last flagged, when it was last notified, the notify count, when actions ran and when it resolved. A finding that no longer reproduces self-closes on the next clean run.
Notification targets are the assignee, the reporter, the watchers, the project lead and named users, with a send-email flag and a renotify-after-days setting where zero means every run. Nobody has to close a ticket about a ticket.
Five configurations are rejected when you press save: a rule with no schedule and no event, a rule with no requirements, a rule with nobody to notify and nothing to do, a ONCE rule with nothing to do, and a filter containing currentUser() — which has no meaning when a scheduler is the caller.
Field and operator pairing is enforced at save too, a condition with no value is refused, and an empty field fails every condition except the one that asks it to be empty.
What starts a run, what it looks at, and how precisely you can describe the thing you object to.
* and ? only. A rule author cannot hand the engine a catastrophic backtracking pattern, and the person reading the rule six months later can still tell what it matches.Every operand is a name, resolved inside the ticket's own organisation — so a rule written once reads correctly everywhere it applies.
Routing is configured per project and applies to every path a ticket can arrive by — the REST API, bulk create, inbound mail, MCP, automation, the issue mirror, AI drafts and the customer portal.
Round-robin reads and writes its cursor under a row lock, so two tickets arriving in the same second do not both go to the same person. Viewers and customers are never eligible, and cross-organisation groups and accounts are refused outright.
That last point is the one that matters in practice. Routing that cannot explain itself gets switched off after the first argument about whose queue is fuller — a preview that names the skipped person and the reason ends the argument before it starts.
Yes. A dry run notifies nobody, records nothing and performs no action — it only tells you what the rule would have found. There is also a Run now for when you do want the rule to act immediately, independently of its schedule.
No. Platform, tenant, organisation and project rules form a union of standards, not a ladder. A project cannot switch off a standard the organisation set; it can only add its own on top. The editors live at Admin → Automation, Settings → Automation and Project Settings → Ticket Quality Rules.
No. Transitions go through the project's own workflow engine, and a refusal is recorded as a failed action rather than overruled. Actions are ordered and applied individually, so one failure costs one action and not the whole run.
Rules also cannot cascade: a write made by a rule raises no further rule, which means there is no recursion depth to tune and no loop to discover the hard way.
Only as often as you tell it to. An action applies once per finding rather than once per run, and notifications honour a renotify-after-days setting where zero means every run.
Per rule and ticket, Trakr tracks the finding, when it was first and last flagged, when it was last notified, the notify count, when actions ran and when it resolved. When the underlying problem is fixed, the finding closes itself on the next clean run.
Deliberately not. Schedules are hourly, daily at a chosen hour, or weekly on a chosen day and hour. On top of that there are five events — created, updated, transitioned, assigned and commented — dispatched after commit on a background thread, so a rule never slows down or rolls back the user write that triggered it.
Each project has a routing rule: a mode of manual, round-robin or least-busy; a pool drawn from project members, a group, a skill or a named list; and a fallback of default assignee, project lead or nobody. Respect-availability skips people who are away rather than letting a delegation redirect steal their turn, and the round-robin cursor is read and written under a row lock.
A live preview on the settings page shows every candidate, whether they are eligible, why they are not, their open-ticket count and who is next. Viewers and customers are never eligible, and cross-organisation groups and accounts are refused.
Write the rule once, dry-run it, and let it hold the line. No cron, no regex, no cascades, no overruled workflows. Made in Belgium.