Automation rules

Admin, Automation (/admin/automation). Needs module.automation.

When a new submission matches your conditions, do something about it.

The shape of a rule

Rules are evaluated on submission creation, in rank order. A null condition matches anything.

Conditions

Condition	Matches on
Repair type	The type chosen when lodging
Priority	The priority set
Coverage	Warranty, insurance, chargeable, or your own

Leave a condition blank and it matches everything, so a rule with no conditions applies to every new submission.

Actions

Action	Effect
Set priority	Override whatever was set
Assign a technician	Give it an owner immediately
Notify	Raise a notification
Stop processing	Do not evaluate any further rules

Rank and stop processing

Rules run in rank order, and by default every matching rule applies. Stop processing on a rule means later rules are skipped for that submission.

Use it for a specific rule that should win over a general one. Put the specific rule at a lower rank number with stop processing on, and the general fallback below it.

Rules worth writing

The test for a good rule is that you are already doing it by hand every day.

Route by type. Cracked screens to the technician who does screens. Everything else to the general queue.

When type is "Damaged display"
  assign to Sam
  set priority High

Escalate insurance work. Insurance jobs usually have paperwork with a deadline.

When coverage is "Insurance"
  set priority High
  notify

Catch the unassigned. A fallback so nothing sits with no owner.

When (no conditions)          [highest rank number, runs last]
  assign to the duty queue

Rules not worth writing

Anything that needs judgement. A rule that sets priority from the description text will be wrong in the case that matters.

Anything you have not been doing manually. If nobody has been triaging this way, automating it does not make it right, it makes it consistent and wrong.

Too many rules. A dozen interacting rules is a system nobody can predict. Six months later somebody asks why a submission was assigned to a person who left, and the answer takes an hour to find.

A bad rule cannot block a submission

Rule evaluation is best effort and never throws to the caller. A rule that fails does not prevent the submission being created.

Losing a repair booking to a configuration mistake is worse than a rule that does not fire.

Creation only

Rules run when a submission is created. They do not re-evaluate on change.

If you want something to happen when a status changes, that is either the email templates, which are already triggered by status, or an outbound webhook driving your own logic.

Auditing

Rule matches are visible as events, and changes to rules are recorded in the audit log.

When a submission ends up somewhere unexpected, the audit log plus the rule list is how you find out why.