Skip to content

Automation triggers

A trigger defines when and where an automation starts. It must be the first step on each path; a flow with no trigger or a trigger with no outgoing path cannot be saved.

The palette’s Triggers tab contains seven types:

SectionTriggerStarts whenContext provided to the path
ConversationsConversation eventone of the seven selected events occursconversation and contact
ConversationsNo reply on conversationan eligible conversation exceeds its silence thresholdconversation and contact
ConversationsCommandsomeone on your team presses the button on the conversation panelconversation, contact, and who pressed it
ContactsContact taga tag is added or removedcontact
ContactsContact added to listmembership changes to subscribedcontact and list data
ScheduleSchedulea one-time or recurring occurrence arrivestiming data; no contact or conversation
CampaignsAudienceit is time to process a listone contact per run; no conversation

Do not confuse these entry points with channel triggers, which create the inboxes through which messages reach SquadOS.

Select one or more events. Each matching occurrence may start a run:

UI eventWhat it represents
is createdthe conversation record was created
is assigned to someonea teammate became responsible
is transferredthe conversation changed hands
is handed to an agentan AI agent took over
is resolvedthe conversation was closed
is reopeneda resolved conversation became active again
has AI turned on or offits AI handling mode changed

Filters are evaluated against the state available at the time of the event. For example, a tag applied after creation does not cause is created to be evaluated again.

“Once per conversation” is not a property of this trigger: it is the automation’s default Re-entry mode. Under Always, each new matching event may create another run and consume credits again in AI steps. See Creating an automation.

Use this trigger for follow-ups. It considers active external conversations where:

  • the last message came from your team and the contact has not replied;
  • the time since that message exceeds Time without a reply;
  • no teammate has taken over the conversation without replying yet — whoever takes over from the screen gets the turn to speak, and the conversation only counts again after that person replies;
  • the conversation is neither deleted nor snoozed until a future time;
  • the contact has not opted out of outbound communication;
  • there is no other active run of this automation for the same conversation;
  • every configured filter is true.

Messages from the AI agent, from teammates, and from automations all count as “your team”. The message this automation itself sent does not open a new cycle: the conversation only enters again after the contact replies, someone on the team speaks again, and the silence starts over.

The initial visible value is 2 hours. The scan runs in cycles of about 15 minutes, so a run is not guaranteed to begin at the exact second the threshold is reached. Right before the first step, the conversation is checked again; if it stopped qualifying in the meantime (the contact replied, someone took over, a filter no longer holds), the run ends as Canceled and the trigger shows as Skipped in Activity.

Under Safeguards, you can enable:

  • Give up after a while — sets the maximum age of the silence. With a 2-hour minimum and a 7-day maximum, conversations between those limits qualify; older history stays out.
  • Wait before entering again — prevents re-entry during the interval measured from the end of the previous run, including a failed or canceled one.

Both safeguards start off. The trigger still prevents two simultaneous runs on the same conversation and starts a new cycle when the team speaks again and the contact goes quiet again.

A follow-up is an organization automation, not an AI agent setting. Without filters, Time without a reply applies to every external conversation that meets the rules above, whichever agent or person is handling it. To limit the follow-up to one agent’s conversations:

  1. Open the No reply on conversation trigger (or create the automation from the Follow-up on a stalled conversation template).
  2. Under Filters, click Add filter and choose Conversation owner.
  3. Keep the verb is and, under who?, pick the agent from the Agents group. To cover more than one agent in the same rule, select several: they are joined by or.
  4. If needed, combine it with Inbox, Channel, Conversation tag, or Contact tag; every filter must be true.
  5. Save and activate the automation.

Conversation owner looks at who is in control right now. A conversation only counts as the agent’s while AI is on for it; if a teammate takes over, the conversation stops matching the filter, even if the agent is still associated with it.

The filter is checked during the scan and again before the first step, but not after a Wait. If the flow has several sends separated by waits and someone takes over during a wait without the contact replying, the later sends still go out. To prevent that, place a Condition before each later send, comparing {{conversation.assigned_to}} with the is empty operator, and connect the None output to End.

When each agent needs different text or timing, create one automation per agent, each with its own filter. The message goes out through the conversation’s inbox, like other automated messages, and the conversation stays with the agent: when the contact replies, the agent handles it as usual, and waits with The contact replies end the follow-up.

Conversation event and No reply on conversation share Add filter. The six criteria offered for new conditions are:

CriterionWhat it checks
Inboxthe current inbox
Conversation ownera teammate, an AI agent, or Nobody; it considers who is currently in control
Conversation tagtags on that specific conversation
Contact tagrecord-level tags shared across conversations
Channelthe API, Email, Instagram, Telegram, or WhatsApp family
Conversation AIOn or Off

Combination rules are:

  • different conditions are joined by AND: every one must be true;
  • within a positive condition, multiple values are joined by OR;
  • a negative condition excludes any selected item;
  • each criterion may appear only once;
  • a condition with no value prevents saving;
  • with no filters, any conversation that satisfies the trigger’s other rules is eligible.

Older automations may display the legacy Agent or Assignee criteria. They are still read, but new conditions use Conversation owner, which combines people and agents without mistaking a previous agent for the current owner.

Command turns the automation into a button your team presses inside a conversation. The button appears in the Commands section of the Conversation tab, in the Context panel, only while the automation is active. Trigger changes take effect after you save the version.

Under The button, fill in:

  • Button name — required; write what it does, such as Check enrollment, not the automation’s name;
  • Button explanation — optional line shown under the name;
  • Confirmation before running — Always ask (default) or Only when the conversation has a warning.

The confirmation shows, under This command will run:, the sequence of steps, highlighting the ones that act outside the conversation, and notes when a Condition may lead to other paths. Below come the effects: sending a message or email, calling an external system, or using AI, which consumes credits. Confirm with Run.

To decide whether to ask for confirmation, SquadOS separates two kinds of flow:

  • Flow that talks to the customer (Send message, Send email, or Send campaign) — always asks for confirmation, even with Only when the conversation has a warning. Only in this case are conversation warnings checked: snoozed conversation, customer waiting for a reply, and daily limit of automated messages reached appear in the confirmation and are waived by whoever confirms.
  • Flow that does not talk to the customer — with Always ask, the confirmation appears if there is a webhook or AI step; with Only when the conversation has a warning, it runs immediately. A flow with no external effect runs immediately in both modes.

Contact opt-out and the Meta 24-hour window do not appear in the confirmation and cannot be waived. If they block a send, the command run fails at that step instead of skipping the send.

Under Who sees it, select the Departments that can see the button.

  • With no department selected, the button appears to everyone who has Use commands; the collapsed section shows Everyone who can use commands.
  • With departments selected, only people in one of them see the button. An archived department no longer counts.
  • The Owner sees every button.

Use commands is a general permission, given to a department or to a person. In every case, the person also needs Reply on that conversation’s inbox. See Departments and access.

Add filter uses the same criteria as Conversation filters, but here they decide which conversations show the button, not when something fires. With no filters, it appears on any conversation from external inboxes.

While a command runs, the button shows Running… in place of its description, the conversation’s other buttons are unavailable, and the same command cannot be started again on that conversation until it finishes. At the end, a notice says whether it finished, is still running, or failed; in that case, check the Activity tab.

The command ignores the Re-entry mode: each click can create a new run. Besides conversation and contact, the path receives {{trigger.payload.invoked_by_name}} (who pressed it) and {{trigger.payload.label}} (the button name), useful in an internal note, for example.

Choose Added or Removed and, optionally, one or more tags. With no tag selected, the trigger applies to any tag for that operation.

A change made by the Apply tag step counts too. This lets automations be chained, but review Re-entry before building flows that add, remove, and reapply trigger tags: under Always, a chain can fire again and repeatedly consume credits.

This trigger provides contact, but not conversation. Before using Send message, Assign, Resolve, Hand off to agent, or Tag conversation, add Get the contact’s conversation and choose the correct inbox.

This trigger fires when list membership enters the subscribed state: on a new membership or an update from another state. A contact who was already subscribed and remains subscribed does not fire it again.

You may select a specific list or leave any list. Manual additions, imports, forms, and the public Lists API pass through the same event when they produce valid membership.

In addition to contact, the path receives:

  • {{trigger.payload.list_name}} — list name;
  • {{trigger.payload.list_id}} — list identifier;
  • {{trigger.payload.consent_source}} — recorded consent source.

Like Contact tag, this trigger does not provide a conversation. Use Get the contact’s conversation before steps that require a customer service thread.

Schedule runs the same path at defined times without selecting an audience. The node starts as recurring, every day at 9:00 AM, and supports:

  • Once — a future date and time;
  • every N minutes or hours, with a minimum interval of 15 minutes;
  • every day, week, or month at the selected time;
  • monthly recurrence on days 1 through 31; a month without the selected day uses its last day.

The clock keeps creating occurrences without waiting for the previous flow to finish. A short frequency may therefore keep several runs active at the same time if the path contains a long wait. Re-entry mode does not deduplicate schedule occurrences.

This trigger provides neither a contact nor a conversation. To act on a person, add Pick contact; for customer service steps, follow it with Get the contact’s conversation.

The runtime provides {{trigger.payload.scheduled_for}} (planned time) and {{trigger.payload.fired_at}} (time when the engine began the occurrence). Both appear under Insert variable in later steps.

Audience processes the contacts in a list at the scheduled time. Unlike Schedule, it creates one child run for each eligible contact.

  • A list is required.
  • Tags are optional; with several selected, the contact only needs one of them.
  • The audience is read when each campaign run begins, not when the automation is configured.
  • Only subscribed memberships, contacts without an outbound opt-out, and records that were not absorbed by a merge are included.
  • Large audiences are processed in batches of up to 500 contacts.

Its schedule supports the same modes and 15-minute minimum as Schedule. For a recurring audience, the next campaign is scheduled after the current fan-out finishes. The browser time-zone issue described above also applies to Once.

Each child run receives contact, but not conversation. An email send can work with a contact/list; customer service channel steps require Get the contact’s conversation.

Different types may start different paths and later converge. At a convergence, a step can only use symbols available on every incoming path. For example, a conversation path and a contact path lose conversation at the convergence until all paths have passed through Get the contact’s conversation. See Variables.

Triggers of the same type have restrictions that prevent two runs for the same occurrence:

  • two Conversation event triggers may coexist when they do not share events. If they share an event and either uses the current filter format, saving rejects them even when the conditions appear different;
  • two Contact tag triggers need operations or tag sets that do not intersect; “any tag” overlaps every set;
  • two Contact added to list triggers must point to different specific lists; “any list” overlaps every list;
  • there may be only one No reply on conversation, one Schedule, and one Audience in an automation.

Every trigger needs an outgoing path. When testing an automation with multiple triggers, select Which trigger to simulate and provide a matching conversation, contact, or payload. Tests ignore re-entry and simulate send actions, but run AI for real, which may consume credits, and make webhook calls for real.

  • The type matches the actual event, and Schedule was not confused with Audience.
  • For Command, Who sees it and the Where it shows filters show the button only to the people who should use it.
  • Required events, minimum time, list, and date are filled in.
  • Filters use the state that will exist when the trigger fires.
  • The context provided by the trigger supports every following step.
  • Re-entry will not turn repeated events into unwanted runs.
  • Schedules and audiences were checked in the correct time zone and at a safe frequency.
  • Each trigger was tested through its own path and its result was reviewed under Activity.