Timers have a trigger condition, a set of steps that can either send emails or update a single field in a record, and a stop condition. Each step can send out an email or update a single field in the record of the table it covers. It was made for sending out reminders, but can also be used for other automatic processes where pauses are suitable between steps.

Timers are complex to enter, but simpler and has better tool support than writing it from scratch as a modification to the code. It is possible to add other actions in additions to email and simple updates in code however.

When a timer is added the base information is entered as well a list of all the required steps. once that is done and saved, open the timer and tweak parameters, For emails the only extra configuration options is the template used and an optional query to get a file attachment to include. The email template itself has all info needed for the email. Update steps simply have a field name and the value to set it to.

From each timer record it's possible to get a preview of all steps to run, and also too see all active timers in the system.


The preview will be empty if the next run of timers doesn't have anything hits on the trigger.

The preview and active timer gives pretty good visibility into the running system, and the active list shows all timers as inline edit fields, so the timers can be modified or stopped if required.

To enter new timers a good understanding of the database layout is required, both for the tables used to initiate the timers and the timer records themselves. The configuration above referes to timers, but is actually stored in timer_type and timer_step. When run the actual instance of each timer is stored in the timer table, pointing to the configuration tables.