Event rules

What happens, as opposed to what is asked: "a youth needs a chaperone", "regional members check in at the venue only", "a chaperone comes on the day of the youth they bring".

Who uses it: an organizer setting up an event (or importing an event template that carries rules); everyone else meets the rules when they register or scan.

What they came to do: write the event's policies once, and trust that every registration and scan follows them.

What must be true when they leave: a rule that names something the event does not have cannot be saved; every time a rule runs, the audit log says which rule and what it did; nothing a rule does is silent.

Decided

• Rules are per event, in priority order, each with a trigger, a condition and actions, and can be switched off.

• On sign-up, each person is checked as they are added and then the submission as a whole: a rule can require a companion, refuse the form with a message (nothing is kept), assign days (including "the days of the people I accompany"), change a type, add a tag, send the registration for approval, or email a role.

• At check-in, a rule can turn someone away with its own message, and say which roles may let them in anyway.

• When a ticket is issued, a rule can tag the person or email a role.

• Conditions read the person, their registration and household, the day, the check-in point, the event and the time; values can be small sums like event.starts_at - 3d.

• Saving needs the Growth plan; discounts, prices, webhooks and the other advanced actions need Scale. After a move down from Scale, rules already saved keep working as they are; the editor no longer offers the advanced actions, and a rule that still has one must lose it before the rules can be saved again.

• A dry-run shows what a draft would do to the last 100 registrations, changing nothing.

• Prices (Scale). A rule on "on price" can take a percentage or an amount off, or set the price, for the whole registration — "15 % off for three dependents or more". Rules run lowest priority first, each on the total the rules before it left; a percentage is of the whole total, rounded to the nearest cent; a price never goes below zero. The price is worked out when someone is asked to pay, and the registration page lists what each rule changed. At checkout the payer sees one line for the amount with the discount named under it ("Family discount −26.25"); a discount code comes off after the rules. Someone who has already paid is never charged again because a rule changed. Dry run shows each registration's price before and after the draft's pricing rules.

• More on Scale. A rule can write an answer on the person or the registration (a fixed value or a small sum), look a value up in a connected integration (none can answer yet), call a webhook, put someone on the waitlist, or allow only so many places per group ("40 per region"). A webhook gets ids, never names, is signed with the secret shown on the Rules page, and has five seconds; at a scan or when a ticket is issued it is sent afterwards so nobody waits. When a lookup, a webhook or a group cap fails, the rule's "otherwise" decides — refuse, or wait — and a full group refuses by default. People a rule sends to the waitlist are moved in by an admin with Promote now. Dry run shows all of it and calls nothing.

• On a schedule (Scale). A rule on "on schedule" runs at the times its schedule says ("0 9 * * 1" is 09:00 every Monday, in the event's timezone) while the event is published or live, once each time, and can email a role or an address or call a webhook. A time missed while the product was down is skipped, not run late.

• The editor is Events → Rules. Nested groups of conditions show as JSON and are kept exactly as written; everything else is a field. Save says what is wrong in words; Dry run shows what the editor's rules would do to the last 100 registrations, saved or not, as a table under the editor: the registration, the rules that matched, the actions they would run, and whether it would be blocked, sent for approval or allowed (Pilot Day, C7).

• Send email lists each email template once, its newest version; where two templates share a name, the code follows it.

Open

• A visual editor for groups of conditions inside groups.
• An approval step for on_approval rules to run on.
• Screens for tags and approval queues (today they are kept with the person's and the registration's answers).