Automation rules: triggers, conditions, and actions

Overview

An automation rule runs actions automatically when an event happens and the conditions you set are met. It's the most direct way to remove repetitive work: assigning conversations, adding labels, sending messages, resolving conversations, moving CRM deals, or notifying external systems via webhook.

Every rule follows the structure trigger → conditions → actions:

• Trigger: the event that starts the evaluation (for example, "conversation created").
• Conditions: filters that must be true for the rule to act.
• Actions: what the platform does when the trigger fires and the conditions pass.

Prerequisites

• Admin permission to access the Automation area under Settings.
• At least one inbox with conversations, so triggers have something to evaluate.
• For actions that depend on other modules (CRM, Catalog, Tasks, Follow-ups), the matching module must be enabled on the account.

Step by step

If there are no rules yet, the page's empty state summarizes what automation does and lets you create the first rule without hunting for another action on the screen.

1. Under Settings, open the Automation area and create a new rule.
2. Give the rule a clear name and description.
3. Choose how the rule runs. The When should this rule run? selector appears when delayed execution is enabled on the account:
   • Run instantly — "Runs the moment an event happens, as long as the conditions match." This is the classic behavior, with the trigger selector and the condition list right below it.
   • Run after a wait — "Waits for a set time and runs only if things are still the same. If they change, the rule is skipped." In this mode the trigger and conditions give way to the Wait condition block, detailed under Settings & options.
4. Choose the trigger (event). The main ones are:
   • Conversation created, Conversation updated, Conversation resolved, Conversation opened;
   • Message created (incoming or outgoing);
   • Contact created, Contact updated, Contact merged, Contact deleted — rules that act directly on the contact record, with no conversation required;
   • Orders: order registered, order status changed, order paid, partial refund adjusted, order refunded, payment reversed and deal orders fully paid (with the Payments/Commerce modules active);
   • Payments: charge created, confirmed, paid, partially refunded, overdue, refunded, failed or canceled. Confirmed means the customer completed the payment although the gateway may make the balance available to the merchant later; paid/received records that later provider stage. Do not create duplicate rules with the same actions for both events;
   • Contracts: contract viewed, signer signed and contract expired (with the Contracts module active);
   • Calendar — two levels, and the difference matters:
     • Booking created / rescheduled / cancelled: the customer booked, rescheduled or cancelled through the public booking page (that is, there is a booking behind it);
     • Calendar event created / rescheduled / cancelled: the appointment itself changed — including when an agent edits, drags or cancels it from the panel, or from the Schedule tab inside a conversation. An appointment that has a booking fires both levels when you change it from the panel; an appointment created straight on the calendar, with no booking, fires only the event level.
   • CRM, Catalog, and Task events when those modules are active.
5. Add conditions. Combine fields (status, priority, inbox, labels, browser language, contact/conversation attributes, CRM fields) with operators such as equal to, not equal to, contains, or does not contain. Contact and order triggers expose dedicated conditions: city, contact type (visitor, lead or customer), blocked, order status, order gateway and order amount — plus the contact's custom attributes.
6. Define one or more actions (see the list below).
7. Save and activate the rule. Test with a real conversation to confirm the behavior.

Settings & options

Available actions (they vary by trigger and active modules):

When the modules are active, module-specific actions appear: move a deal between stages, assign and set value/priority in the CRM, add a product to a deal in the Catalog, create tasks, and enroll the contact in a Follow-ups sequence.

On the contact triggers (created/updated/merged) the rule runs against the contact — and now offers the whole contact-anchored catalog: beyond the contact actions (labels, note, attribute), you can create a CRM deal already linked to the contact, move a stage, create a task or appointment tied to the contact, send charges and subscriptions, enroll in follow-ups and contracts, run engagement and WhatsApp group actions (the default participant is the contact itself), fire a webhook, and launch a mass flow run. Actions that operate on a conversation (assign agent/team, resolve, send message/note/attachment, SLA, AI/Maestro, WhatsApp template) remain unavailable on these triggers because there is no conversation — use Create conversation to chain into a conversation trigger.

• "AND" conditions: every condition must be true for the rule to act.
• Order: actions run in the order they appear in the rule.
• Enable/disable: you can pause a rule without deleting it.

Actions by trigger

The action list is scoped by the trigger's subject: each trigger offers every action its subject can actually run — so you build the complete rule without combinations that would never fire.

• Conversation and message triggers (conversation created, updated, opened, resolved and message created) offer the full catalog of actions.
• Contact triggers (created/updated/merged) offer the whole contact-anchored catalog: CRM (create a deal already linked to the contact, move a stage), tasks and appointments tied to the contact, charges and subscriptions, follow-ups, contracts, engagement, WhatsApp group actions (default participant = the contact), webhook and mass flow run. Actions that operate on a conversation are left out (there is no conversation) — chain with Create conversation.

Subscriptions: what fires and what does not

A subscription created in the gateway dashboard is adopted here and does fire the rule: as far as the platform is concerned it is happening now, already filtered by the connection's cutoff date. A subscription brought in by a history import never fires — it is the past, and replaying it would open deals and send notifications about old sales.

An adopted subscription can arrive with no linked customer. Actions that need a person (opening a deal, messaging, scoring) have nobody to address, and a deal with no contact, company or conversation is refused rather than becoming a useless card in the funnel. To act only when there is somebody on the other side, add the Subscription linked contact condition with "is present".

• Contact deleted trigger: because the record no longer exists, it offers only webhook and fully parameter-driven actions.
• Order triggers anchor on the order's contact — every contact-anchored action is available.
• Task, calendar, WhatsApp group, subscription, commerce, contract, engagement, CRM and ads triggers gained the full catalog their subject supports — including conversation actions when the subject has a linked conversation (for example, a task with a linked conversation or a group with the group's conversation).

When you create a new rule (or switch the trigger), the selector already comes with the first valid action for that trigger pre-selected — you never again open a new rule and find "Assign to Agent · Not available for this trigger".

If you edit an older rule that holds an action no longer belonging to the current trigger, that action stays visible with a "Not available for this trigger" tag. It is not removed: the rule is still saveable and you can swap it for a compatible action whenever you want.

Actions with no parameters

Some actions ask for no extra field because they resolve the context on their own from the trigger. They save without requiring parameters, in both Automations and Macros:

• Cancel, pause, resume and skip step for follow-ups;
• Send charge and cancel subscription;
• Send product card;
• Pause ad campaign, send conversion and tag as ad lead.

When an action doesn't apply

If an action depends on something that doesn't exist in that context — for example, a conversation action on a trigger that has no linked conversation — it is skipped and logged, without breaking the rule: the remaining actions still run normally.

Variables in actions ({ } Insert)

Every text field the platform resolves at run time shows the { } Insert button and opens the variable list when you type {{. The chosen variable goes where the cursor is and the rule window stays open. The same fields accept variables in Automations, Macros and the Flow Builder — in a flow, those fields also resolve {{ vars.* }} and {{ steps.* }}.

Fields that deliberately do not accept variables:

• Pickers (agent, team, label, pipeline, stage, inbox, connection): the value comes from the list.
• Webhook URL: the destination is fixed for security; the conversation or contact data already travels in the webhook body.
• Amount of charges and subscriptions: it is money sent to the gateway and never comes from text.
• Order gateway, template language and namespace: they are identifiers.
• Additional attributes and the number and date fields of the rule editor (for example, the deal value in "Set value"): in the Flow Builder form the deal value accepts a variable.

Which variables the list offers depends on the trigger:

• Conversation and message: contact, conversation, inbox, agent, team, SLA, account and the modules (CRM, company, payment, order, calendar, task, contract and others).
• Contact and company: there is no conversation — the list hides conversation, inbox, agent, team and SLA.
• Payments: {{ payment.* }} describes the charge that fired the rule. CRM: {{ crm.* }} describes the deal that fired the rule.
• The other contact-linked modules (order, calendar, task, contract) use the contact's most recent record.
• Rules and macros never offer the Flow Builder-only variables (vars, steps, trigger) nor those of other screens (product, campaign, group, article).

When a variable has no value, that part of the text is left blank — the customer never receives {{ ... }}. In fields that are data (phone, invitee email, IDs, amounts and dates), the action is skipped and logged instead of saving a wrong value. The phone is normalized to the international format after the variable is resolved, so 55 11 98888-7777 becomes +5511988887777.

A variable's value is always treated as text: if a contact name, an attribute or a customer reply contains {{ }} or {% %}, it shows up exactly as it is — it is never executed — and in the team email it never becomes HTML either. A template that produces too much text or loops without end is stopped and left blank.

The rule form

The rule opens as a modal window over the list, anchored to the top of the screen and scrolling on its own: the whole form fits in there, from the name down to the actions. Condition and action menus open inside that window — a deliberate choice on this platform, so that no dropdown ends up hidden behind the modal.

The field order is always the same: name, description, the When should this rule run? selector (when delayed execution is enabled) and, below it, the trigger and the conditions — or the Wait condition block, if you pick the wait. Actions come last, followed by the cancel and save buttons.

A few details that prevent surprises:

• Switching between "run instantly" and "run after a wait" does not lose the duration you typed. The value is held by the form, so you can move back and forth between the two cards without typing "4 hours" again.
• When you reopen a rule with a wait, the time is shown in the largest whole unit: 240 minutes reads as "4 hours"; 2,880 minutes, as "2 days".
• When you turn an instant rule into a rule with a wait, the instant editor's conditions are replaced by the conditions of the wait trigger you chose. That is deliberate: a filter left over from the previous editor would arm the clock on the wrong event.
• In the wait block the status comes pre-filled with Pending; the options are Open, Resolved, Pending and Snoozed — "All" is not offered here, because a wait needs one concrete status to count against.
• On a new rule, changing the event warns in plain text: "Changing event type will reset the conditions and events you have added below".
• Triggers whose subject has no filterable field at all (WhatsApp group, catalog and others) simply don't show the conditions section — instead of rendering an empty condition row.

Rules with a wait: run after some time has passed

Delayed execution is controlled by the Delayed Automations feature (delayed_automations), which ships turned off and is enabled per account. With it on, the rule form gains the When should this rule run? selector, with two card options: Run instantly and Run after a wait.

When you pick the wait, the trigger and the condition list give way to the Wait condition block, with four fields:

Next to the fields there is a side panel with an information icon. It explains in plain sentences what the chosen combination means, using the same unit you typed ("4 hours", "2 days"):

• Conversation stays in a status — "The clock starts when a conversation moves into this status. If it is still there {duration} later, the actions below run. If the status changes before then, nothing happens."
• Customer hasn't replied — "The clock starts when a teammate replies. If the customer hasn't written back {duration} later, the actions below run. If they do reply, nothing happens, and the next teammate reply starts the clock again."
• No teammate has replied — "The clock starts when a customer sends a message. If no teammate has replied {duration} later, the actions below run. If someone replies before then, nothing happens."

The same panel carries the footnote: "Only new activity starts a clock. Conversations already sitting in this state are picked up the next time something happens on them."

Two precisions the panel has no room to explain, and that change the outcome:

• On Customer hasn't replied, every new teammate reply pushes the due time forward: the clock now counts from the most recent reply. A burst of team messages moves the deadline along; it does not stack up several deadlines.
• On No teammate has replied, the clock is the one of the customer's first unanswered message. If they send three more messages in a row, the deadline keeps counting from the first one — it does not restart with each message.

Wait limits

• Minimum of 10 minutes and maximum of 30 days (43,200 minutes). The field clamps a value outside that range to the nearest bound — when you leave the field, press Enter or change the unit. Typing 5 minutes leaves 10. The error "The wait must be between 10 minutes and 30 days" appears when you try to save with the duration field empty.
• The duration suggested on a new rule is 4 hours.
• When you switch units, the minimum follows: in days, the smallest possible value is 1 day.
• A private note is an outgoing message. That is why the Customer hasn't replied option adds a filter of its own that ignores internal notes — a team note doesn't restart the clock.

What a wait does not accept

• Conditions using the attribute changed operator (attribute_changed): the re-check done at run time cannot reconstruct what changed, so the rule is refused on save.
• On conversation triggers, only status and inbox can be used as conditions. The other fields change during the wait and would blend distinct stretches into a single clock.

Editing a rule with a wait clears the clocks in flight

Changing the trigger, conditions, actions or duration — or simply turning the rule off and on — discards the waits already armed. They arm again on the next matching event. This is deliberate: a rule switched off and back on before its due time must not run exactly the actions you switched it off to prevent.

One exception: a wait that has already started running the actions is not interrupted — what is in flight cannot be called back. Everything that was still only waiting is discarded.

How the list separates instant rules from rules with a wait

When the account can create rules with a wait (or still has one), the list gains two tabs with counters: Runs instantly and Runs after a wait. Creating a rule from the second tab opens the form with the wait already selected.

• Each rule with a wait shows the badge Runs after {time} next to its name, written in the largest whole unit: 30m, 4h, 2d.
• The wait tab with no rules shows "No rules run after a wait yet".
• Every row carries three action icons, each with a hover tooltip: Edit, Clone and Delete. In the form, every rule action has its own icon too (an envelope for the email transcript, a tag for labeling, a crossed-out bell for muting, a clock for snoozing, and so on) — the same icons appear in Macros.

The full set of action icons: a person (assign agent), rounded people (assign team), a person with an X (remove agent), people (remove team), a tag (labeling), a tag with a minus (remove label), an envelope (email transcript), a paper plane (email to team), a speech bubble (send message), a sticky note (private note), a paperclip (attachment), a webhook, a crossed-out bell (mute), a clock (snooze), a circle with a dot (reopen), a dashed circle (mark as pending), a circle with a check (resolve), signal bars (priority) and a gauge (SLA). Any action without its own icon uses the lightning bolt.

The header also carries the search box ("Search automation rules..."), which filters by name and description at once and applies to both tabs — the counters follow the filter. With no match, the table shows "No automation rules found matching your search". Next to the tabs sits the count of the rules visible in the current tab.

The table has four columns: Name, Active, Created on and Actions. The date column shows the day; the full time appears on hover. The Active switch asks for confirmation before turning a rule on or off, and the question names the rule ("This action will deactivate the automation rule '...'").

When the wait is turned off

If the feature is disabled and the account still has rules with a wait, a highlighted banner appears above the list: "Delayed execution is turned off for this account, so the rules below that run after a wait are paused until it is turned back on."

In that state:

• The waits already armed are not deleted — they sit still. When the feature is turned back on, the ones that went past the 3-day limit during the pause get a fresh due time of now, instead of being dropped as expired; the rest simply come up in the next sweep. All of them go through the normal re-check before running.
• No new wait is armed, and the rule does not start running instantly: silently becoming instant would be worse than not running.
• Cloning a rule with a wait is refused, instead of creating a copy that would fire immediately. The screen shows the generic notice "Could not clone automation rule, Please try again later"; the specific reason comes back in the API response ("Delayed automations are not enabled for this account.").

How a wait runs behind the scenes

Knowing this helps you read what you see on screen:

1. When the event happens and the conditions pass, the platform schedules the execution instead of running the actions. The clock starts at the moment of the event — not at the moment processing happened — so a backlogged queue still fires on schedule.
2. Every 5 minutes a sweep collects the executions that came due and hands them to the workers.
3. Before running, the platform re-checks everything: is the rule still active? Does the conversation still exist? Is it still the same stretch (the status didn't change, nobody replied)? Are the conditions still true? Any "no" records the reason and drops the execution without running the actions.
4. An execution more than 3 days past due never runs — that keeps a long outage from dumping old messages all at once. Finished records are purged after 30 days.
5. Actions are never repeated: if something fails after they started, the platform does not re-run them. Re-sending a message, email or webhook is worse than not sending it.

Two safeguards complete the picture:

• Each sweep hands over at most 1,000 executions. The overflow waits for the next sweep, 5 minutes later, and whoever runs the installation can change that ceiling. Accounts with delayed execution turned off do not consume that budget — one paused account's backlog never delays the others.
• A worker that dies before acting has its execution reclaimed after 15 minutes and handed back to the queue. A worker that dies in the middle of the actions is not repeated, for the same reason as item 5.

Every discarded execution keeps the reason, which makes diagnosis direct: expired (more than 3 days past due), rule_inactive (the rule was turned off), conversation_gone (the conversation no longer exists), episode_moved (the stretch ended — someone replied or the status changed) and conditions_changed (a condition stopped being true).

One detail that explains the panel's footnote: a wait on status only arms when the conversation has a record of when it entered its current status. Conversations that predate the feature have no such record — they start counting on their next status change, instead of all coming due at once on the first sweep.

Sending the transcript to the contact's email

The Send transcript by email action accepts a comma-separated list of addresses, and each address goes through variables before sending. To send the history to the customer themselves, write:

{{contact.email}}

You can combine a variable and a fixed address: {{contact.email}}, supervisor@yourcompany.com. Other contact variables work in this field too (for example {{contact.custom_attribute.billing_email}} for a custom attribute). Only use the variable on rules whose conditions guarantee a contact with an email on file — with no email there is nothing to resolve. Sending only happens when email transcripts are enabled for the account, and it respects the account's email limit.

Two details about the field: all whitespace is stripped before the list is split on the commas — {{contact.email}} , supervisor@yourcompany.com behaves exactly like the version without spaces. And the field resolves the same variable set as the reply composer (contact, conversation, inbox, account and the active modules), not only the contact ones. If the account hits its email limit mid-list, the remaining addresses of that send are left out.

Use cases

• Channel routing: conversations created on the sales WhatsApp go to the Sales team.
• Keyword triage: if the message contains "invoice", add the "billing" label.
• After hours: when a conversation is created outside business hours, send an automatic message.
• Queue hygiene: resolve conversations with no reply for a long time and notify the team.
• CRM: when a lead's conversation is created, create a deal and assign it to the right rep.
• Customer went quiet (with a wait): if the customer hasn't replied 4 hours after the team's last reply, label it "no reply" and create a follow-up task.
• First response running late (with a wait): if no teammate replies within 30 minutes, notify the team by email and raise the priority.
• Stalled queue (with a wait): a conversation sitting in "Pending" for 2 days, resolve it and send the transcript to the contact's email.

Tips, limits & best practices

• Use descriptive names and keep each rule focused on a single goal.
• Avoid conflicting rules that try to do opposite things on the same conversation.
• For actions that send automatic messages, respect channel limits (WhatsApp anti-ban best practices).
• Test in a sandbox inbox before applying the rule to production.
• Document for the team what each rule does — it makes future maintenance easier.
• Start with generous waits (hours, not minutes) and shorten them once you've seen the result: a wait that is too short fires on conversations that were still being handled.
• The wait is a continuous clock, not a business-hours one: 12 hours starting at 8pm come due at 8am the next day.
• When you enable delayed execution, conversations already sitting in that state don't start counting on their own — the clock starts on their next activity.
• Restrict the rule by inbox when the acceptable response time differs per channel.

Troubleshooting

• The rule didn't fire: confirm the trigger and that all conditions are true; check the rule is active.
• The action didn't run: verify the referenced agent, team, or label still exists; and that the action's module (CRM, Catalog, etc.) is enabled.
• The rule acted on the wrong conversation: the conditions are too broad. Refine the filters.
• An action was skipped: some actions only run when there is a conversation in the trigger's context; otherwise they are logged and skipped without interrupting the rule. Prefer an action that is compatible with the chosen trigger.
• An action shows a locked value, just a number: the action points to a record of a module that is off for the account or that your role cannot open (for example a follow-up sequence or an SLA policy). A locked value can also mean the list has not loaded, its request failed, or your access role's list does not include the record (it may be outside your reach or removed). The hint explains the cause. The saved reference is kept unchanged when you save unrelated changes. Reload the page to retry a failed list; for restricted access, ask someone with access or turn the module back on.
• An action shows a number instead of a name: the record may be outside the loaded page of a long list or may have been removed. A prepared batch can also appear only by its identifier. When a lookup confirms removal, the field identifies it as removed. The value stays selected and is saved unchanged; choose another item only if you want to change it.
• The webhook didn't arrive: check the endpoint URL and that it responds successfully.
• The rule with a wait never ran: the most common reason is that the stretch ended before the due time — someone replied, the status changed, or a condition stopped being true. Also check that the rule is still active and the conversation still exists.
• Every rule with a wait stopped at once: look for the banner above the list. It means delayed execution was disabled for the account; turning it back on reschedules the waits that came due.
• I want to know why a wait was discarded: the reason is recorded on the execution itself — expired, rule_inactive, conversation_gone, episode_moved or conditions_changed. Ask whoever runs the installation to look it up when the behavior isn't clear.
• Waits are coming due late: each sweep hands over up to 1,000 executions and runs every 5 minutes. A backlog larger than that is drained across the following sweeps.
• I can't save the wait: remove conditions that use the attribute-changed operator and, on conversation triggers, keep only status and inbox.
• I can't clone a rule with a wait: the generic clone-failure notice appears because the feature is disabled on the account. Enable it again before cloning, so you don't end up with a copy that lost its wait.
• The wait block doesn't appear in the form: the Delayed Automations feature is not enabled for the account.

CRM stage changes

Use CRM deal stage changed and choose the stage in the conditions. Only an actual move triggers the rule; reordering a card inside its current column does not start another execution.

Attachments (including PDF) and Meta conversions use the deal’s linked conversation. If the link is missing, that action is recorded as skipped; the webhook can run independently. Check the inbox conversion settings and attach files to the rule itself. Queuing a conversion does not prove Meta accepted it: inspect the conversion delivery record as well.

For delayed execution, the clock starts at the stage change. At execution time the system checks the stage, conditions and active rule again. Pausing the feature preserves pending actions. Reactivation resumes eligible actions; work overdue by more than three days is marked expired. Editing or disabling the rule cancels pending work from its previous definition.

Each action keeps its own outcome. Replaying an event or restarting a worker does not repeat completed actions. If an external integration may have acted before a failure, its outcome remains uncertain and needs reconciliation before another send. Do not replay historical stage moves in bulk to recover a rule: that can trigger valid commercial effects again.

See also

• Automation & Flows overview
• Automation triggers about the AI (Maestro)
• Macros: reusable actions
• Flow Builder: visual conversational flows
• Smart Routing