Triggers and conditions

A trigger is the event a rule listens for, and conditions decide whether the rule acts on a particular occurrence of it. Every rule has exactly one trigger and any number of conditions. This page lists all ten triggers, the data each one makes available, and the operators the condition builder offers.

Ten triggers exist: eight fire from events in your space, two are only ever run by hand. Changing a rule's trigger changes both the fields the condition picker offers and the variables its actions receive.

Every payload also carries three variables that are not repeated per trigger: space, event_name (a short description of what happened) and trigger_name. The fields on each object are listed in Automation scripts.

Event triggers

Four things about this table are worth knowing before you build a rule on it:

• Member changed tells a new member from an updated one by whether previous is there. It is absent when the member has just joined.

• Question created or replied fires on newly created questions, where there is no reply, and on new replies written by a participant, where reply is present. Replies written by jury — including replies posted by an agentic rule — do not fire it, so a rule cannot answer itself in a loop.

• Contest score changed fires once per score update, repeatedly through a contest. A rule on this trigger has to be safe to run many times, or use a reference key.

• The related objects — contest, participant, member — are included only when they can be looked up. A rule has to tolerate their absence.

Manual triggers

Manual triggers never fire on their own. They exist for one-off jobs, for staff-facing buttons on contest and member pages, and for testing. Changes to a contest's participants — medals, official status, extra time — do not affect an already finalized result, so those are made with Contest action before finalizing rather than from Participant finalized.

What the Trigger dialog asks for

Running a rule by hand needs the entities its trigger describes. The dialog asks for these references, with pickers where one exists:

The dialog also has its own Dry run checkbox, which forces that one run to be a dry run whatever the rule's own setting is.

The condition builder

A condition tests one field of the event data. All top-level conditions must match, and with no conditions the rule acts on every event of its trigger.

Fig 1. A condition on a rule: the field picker, the operator, and the value.

The field picker offers the fields belonging to the selected trigger, grouped by object — Submission, Contest, Participant, Member, Previous, Score, Result and Question. Choosing a known field fixes the comparison type. Custom field… takes any dotted path into the event data, such as score.breakdown, and is always compared as text.

The same picker offers three logical operators, which turn the condition into a container for nested conditions:

Nesting is unbounded.

A condition on a field the event does not carry can never match, and nothing in the console reports it. The rule simply looks as though it never received the event.

Operators by field type

Timestamp conditions never match

Do not build a rule on a timestamp condition. Timestamps in the event data are text in RFC 3339 form, and the timestamp comparison expects a real date value, so a timestamp condition placed on a payload field evaluates to false and silently suppresses the rule.

Compare times inside a script action instead, with time_diff — see Automation scripts.

The Result fields on Participant finalized never match

For the Participant finalized trigger the field picker offers a Result group — result.rank, result.medal, result.score and the rest. Those fields no longer exist in the event data. The trigger now provides row and score instead, so any condition built from the Result group never matches and the rule never acts.

Use a Custom field… naming the field on the object that does exist: row.rank, row.medal, row.score, row.penalty, row.unofficial, row.disqualified or score.solved. Bear in mind a custom field is compared as text, so a rank or a score has to be matched as text rather than with the numeric operators. Where that is awkward, drop the condition and filter inside the script action instead, where row and score are ordinary objects.