Event Handlers

Event handlers are workspace triggers. When an emitter fires — a table change, Gmail, Drive, or WhatsApp — Vettero runs either a handler workflow or a mapped existing resource (agent, workflow, function, query, or chat widget).

Inbound HTTP APIs live under HTTP Servers, not this menu. Recurring cron lives under Schedule (Repetitive), not this menu.

They are not channels (inbound chat sessions with a default agent). They are not Schedule one-time datetime or timeout jobs.

Prefer Free-form workflow unless a single existing resource is enough and you do not need extra blocks.

Triggers

See Triggers for the full list of event types (table changes, mail, and WhatsApp). Types that need a connected service appear in the product only when a matching connection exists.

When to use

• Automate when table rows are inserted, updated, deleted, archived, or when a field changes or a field action fires
• Handle inbound Gmail, Drive file changes, or WhatsApp in a flow instead of (or alongside) a channel default agent

Create an event handler

Open Build → Event handlers (workspace-wide) or the Event handlers panel on an agent or assistant (scoped to that agent). Click Create event.

The wizard walks through:

1. Event type — pick from the grid. Types that need a connected service appear only when a matching connection exists.
2. Name and description — required name so the handler is easy to find.
3. Payload — type-specific config (table, mailbox, and so on).
4. Run condition — optional filter on event args, or skip so the handler always runs.
5. Handler mode — Free-form workflow or Linear resource mapping.
6. Mapping target (mapping mode only) — pick an agent, workflow, function, query, or chat widget, then map inputs and, when the emitter needs a response, outputs.

After create, the detail view opens for that handler.

Configure the handler

Delete from the danger zone. Soft-deleted handlers go to Trash.

Handler modes

Free-form workflow

Vettero creates a system-managed handler workflow. Extend it in the workflow builder (query a table, send a notification, branch, and so on).

You cannot delete that flow as a normal workflow. Disable the handler or delete the event handler instead.

Linear resource mapping

The handler invokes one existing resource on a fixed graph (main → resource → return). You cannot edit that graph as a free-form flow.

Map event input (args.*) into the resource’s input schema. When the emitter requires a response (for example HTTP wait-for-flow with validate response), map resource output (res.*) or event fields (args.*) into the emitter’s output shape.

Run condition

Optional filter on event input. Paths are args.* from the emitter’s input schema (same fields you map in input mapping).

If there is no condition, the handler runs whenever the emitter fires and the handler is Enabled.

Changing payload (for example a different table) can change available args.* paths — re-check the condition after you save payload.

Limits

• Inactive handlers do not run.
• Mapping-mode graphs are not freely edited in the workflow builder.
• System-managed handler workflows cannot be deleted as ordinary workflows.
• Payload changes can invalidate input mapping, output mapping, and run conditions.
• Service-backed types need a connected service with the matching capability enabled.

Where event handlers are used