## 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):

| Action | What it does |
| --- | --- |
| Assign agent | Routes the conversation to a specific agent. |
| Assign team | Routes the conversation to a team. |
| Add label | Tags the conversation with one or more labels. |
| Send message | Sends a message to the contact. |
| Send email to team | Notifies the team by email. |
| Send transcript by email | Emails the conversation history. |
| Mute conversation | Mutes the conversation. |
| Resolve conversation | Closes the conversation automatically. |
| Send attachment | Attaches a file to the conversation. |
| Fire webhook | Sends the event to an external endpoint. |
| Add contact label | Tags the **contact** (not the conversation) with labels. |
| Remove contact label | Removes labels from the contact record. |
| Add contact note | Logs an internal note on the contact record. |
| Set contact attribute | Writes a value into a contact custom attribute. |
| Launch mass run | Starts a mass run of a published Flow Builder flow. |

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.* }}`.

| Action | Fields that accept variables |
| --- | --- |
| Send message, Add private note | Message |
| Send an email to the team | Message |
| Send transcript by email | Emails |
| Create contact | Name, email, phone, identifier, tax ID, tax country and custom attribute values |
| Create conversation | First message |
| Add note to contact | Note |
| Set contact / company attribute or field | Value (text) |
| Set contact affiliate | Referral code |
| Create CRM deal | Title, description, contact email and phone, value, dates and custom attribute values |
| Deal attribute, status and messages | Attribute value, close reason, note, checklist item, message |
| Create task, Comment on task | Title, description, due date, custom attribute values, comment |
| Create, cancel and invite on an appointment | Title, description, location, start, end, custom attributes, reason, invitee email |
| Create charge, Create subscription | Description |
| Register order | Title, amount, external ID |
| Sales | Points metric, transfer and reward reason |
| WhatsApp (groups and contacts) | Phone, contact name, community announcement |
| Send WhatsApp template or Flow | Template variables, header and content; Flow button, body, header and footer |
| Ask Maestro | Question |
| Adjust ad budget | Daily budget |

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:

| Field | What you fill in |
| --- | --- |
| **When** | The situation that starts the clock: **Conversation stays in a status**, **Customer hasn't replied** or **No teammate has replied**. |
| **Status is** | Only shown for the first option: the status the conversation has to stay in. |
| **For** | The duration, in minutes, hours or days. |
| **Inbox** | Restricts the rule to specific inboxes. With none selected, it applies to all of them. |

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](/hc/ajuda/articles/automation-flows-overview-en)
- [Automation triggers about the AI (Maestro)](/hc/ajuda/articles/automation-flows-gatilhos-de-ia-en)
- [Macros: reusable actions](/hc/ajuda/articles/automation-flows-macros-en)
- [Flow Builder: visual conversational flows](/hc/ajuda/articles/automation-flows-flow-builder-en)
- [Smart Routing](/hc/ajuda/articles/automation-flows-smart-routing-en)