Skip to main content
A trigger rule is an event, a condition, and an action. It is how “text the customer when their call rings out” or “make anything from an enterprise account urgent” becomes configuration instead of an integration project. Rules live under Settings, then Triggers, in three tabs: Rules, Sources and Activity.

​
Sources

Four families of event can drive a rule.

Vorel's own lifecycle

Leads, conversations, bookings and calls. Anything happening inside the platform that involves a contactable person.

Your CRM

Every normalised CRM webhook event feeds the engine, so a stage change or a new deal in your CRM can drive a rule here.

Product analytics

Connect your analytics tool and act on product events. Segment, Amplitude, PostHog and Mixpanel cohorts are supported.

Your own webhook

A signed generic endpoint for anything else. You get a URL and a secret.
Each source is connected in the Sources tab and gets its own ingress URL and credential. Signatures are verified, replays are rejected, and duplicate deliveries are deduplicated, so an at-least-once sender cannot fire a rule twice.

​
Conditions

Conditions are built in the rule editor rather than written as code: match on event properties, and combine them with all-of and any-of groups. Conditions fail closed. A condition that cannot be evaluated, because a property is missing or the shape is unexpected, does not match. A rule never fires on a maybe.

​
Actions

Two families. Conversation actions change a conversation in your inbox: Conversation actions require an event that carries a conversation, so they are only offered on the events that have one. Picking an event that does not support them switches the rule back rather than leaving it half built. Outbound actions place a call. See Outbound for the consent and pacing gates that apply before anything dials.

​
Timing

A rule can fire:
  • Immediately when the event arrives
  • After a fixed delay
  • Relative to a date on the event, for example two hours before a booking’s scheduled start
The relative mode is what makes appointment reminders a rule rather than a feature.

​
Throttles

Every rule carries a cooldown per contact, so a noisy source cannot produce repeated contact with the same person. The default is generous, and you can tighten it.

​
Testing a rule

The editor has a dry-run panel. Paste or pick a sample event and see whether the rule matches and what it would do, without anything happening.

​
The activity tab

Every event the engine received, whether it matched, and what happened. This is where you go when a rule did not fire and you need to know whether the event arrived at all, failed the condition, or was suppressed by a cooldown.

​
What replaced the old automation story

Earlier versions of these docs described running workflows in a separate self-hosted automation tool alongside Vorel. That is no longer how automation works here. The trigger engine is built in, and the events it consumes are the same ones available as webhooks if you prefer to act on them in your own systems.