> ## Documentation Index > Fetch the complete documentation index at: https://docs.vorel.ai/llms.txt > Use this file to discover all available pages before exploring further. # Triggers > Rules that fire on an event and do something: call the customer, assign the thread, set priority, add a label. 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. Leads, conversations, bookings and calls. Anything happening inside the platform that involves a contactable person. Every normalised CRM webhook event feeds the engine, so a stage change or a new deal in your CRM can drive a rule here. Connect your analytics tool and act on product events. Segment, Amplitude, PostHog and Mixpanel cohorts are supported. 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: | Action | Effect | | ------------ | ----------------------------------- | | Assign | Give the conversation to a teammate | | Set priority | Urgent, high, normal or low | | Add label | Tag it | | Star | Flag it | | Snooze | Push it out until later | | Unsnooze | Bring it back now | 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](/automation/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](/integrations/webhooks) if you prefer to act on them in your own systems.