Webhook conditions: fire on the changes you mean

An unconditioned webhook on a busy table is a firehose. Most automations want a slice — paid orders, plants below reorder level, records assigned to Salma — and conditions are how a webhook names its slice.

They are deliberately the same conditions you already know. A webhook's Conditions rows are the Filter panel's grammar, row for row — same fields, same operators, same and/or — because a trigger and a filter that use the same words must never disagree about which records those words describe. If you can build the view, you can build the trigger.

Conditions need one table

Conditions name fields, and only a table has a field list — so a webhook on any table offers none. Pick a table and the Conditions rows appear under the sentence.

Empty conditions mean every event of this type. Anything else means only events whose record matches.

What "matches" means, per trigger

• a record is created — the new record is checked; it fires if it matches. When a record is created in Orders with Total is greater than 1000 skips the small ones.
• a record is updated — the record after the edit is checked. While a record keeps matching, every edit to it keeps firing — this trigger asks "does it match now?", not "did it start matching?". (For started, keep reading.)
• a record is deleted — the record's final state is checked, so Status is New means "fires only when an order that was still New gets deleted".

Watched fields: which edits count

a record is updated has a second clause: Watched fields. Name fields there and only edits that touch one of them fire the webhook; a change to anything else is ignored. Empty watches every field.

Two details worth knowing:

• A field counts as touched when an edit writes it — including writing the same value back. changed_field_ids in the payload lists exactly these.
• Computed fields — formulas, lookups, rollups — can't be watched. Their values are derived, never edited directly, so a webhook watching one would never fire; Tabla doesn't offer them.

Watched fields and conditions combine: watching Status with Paid is checked reads "when Status changes on a paid order".

"Starts matching": the transition trigger

a record starts matching is the one most automations actually want, and its semantics are precise: it fires at the moment a record goes from not matching to matching — and only then.

On the demo database's Orders table, a webhook with Status is Out for delivery behaves like this (each case run for real):

• Status edited Preparing → Out for delivery: fires, once.
• The record edited again while Status stays Out for delivery: silent — it already matched.
• Status edited Out for delivery → Delivered: silent — leaving is not an event this trigger has. (If you need "stops matching", invert the conditions on a second webhook.)
• Status edited back to Out for delivery later: fires again — it's a fresh transition in.
• A record created already matching: fires — creation is a transition from nonexistence, which matches nothing.

With no conditions at all, nothing can ever go from not-matching to matching except creation — so it degenerates into a created trigger, and the panel says so.

Editing the conditions, the table, or the trigger resets the webhook's memory of what already matches: whatever matches under the new terms is adopted silently, and only records that begin matching afterwards fire. Narrowing a condition and widening it back doesn't re-deliver everything in between.

Conditions a clock can make true

A date condition's value can be a moment — today, now, offsets like one week from now — instead of a fixed date. Those resolve when the question is asked (days in the database's timezone), which gives a starts matching webhook a second way to fire: time passing.

Deliver by is on or before today becomes true for a record at midnight, with nothing written. So when a matching-trigger's conditions name a moment, Tabla also checks them on a clock — about every 30 seconds — and the panel notes it: Checked continuously — this can fire when time alone makes a record match. A delivery fired by the clock has before: null and an empty changed_field_ids, because no edit happened; the record's state rides in after as always.

Run for real: a webhook with Placed on or before now, then a record created with Placed 75 seconds in the future — silent at creation, delivered 12 seconds after its moment passed.

The edges, stated plainly

• Renaming a select choice doesn't break a condition on it — conditions store the choice's id. A condition on a deleted choice matches nothing (and never blocks anyone's edit).
• The API's filter grammar allows one level of nested groups — A and (B or C). A webhook can carry such conditions if set over the API, but the webhook screen draws flat rows only; it shows grouped conditions read-only rather than flattening them.
• Bulk writes of 50 or more records fire no webhooks at all, conditions or not — see the overview.