Actions catalogue

Actions are the verbs of an automation. Each branch has an ordered list of actions that runs top to bottom when the branch matches, and a failing action does not stop the ones after it. The actions shown in the builder depend on the selected trigger, because each trigger exposes only certain context objects such as a conversation, contact, case or Issue. This reference covers all 36 action types available across the builder, grouped by category. (Four more — snooze, update contact fields, create a side conversation and link a conversation to a case — exist in the model but are marked coming soon and are filtered out of the picker.)

Triggers that do not expose a conversation, contact, case or Issue context have a smaller action set. Incident, trend, schedule and business-hours triggers only offer context-free actions such as email, email template, notification, Slack, webhook, create task and wait.

Communication

• Send auto-reply message — Reply on the conversation’s own channel — email, SMS, Messenger, Instagram, web chat — using inline content and fields
• Send email template — Render and send a designed template from Email Studio, with language selection that can follow the customer or inbox language, or be set explicitly
• Send WhatsApp template — Send an approved WhatsApp template to the customer’s phone, on a conversation of any channel. You pick the sending number and the template, and fill one field per template value — each one can use fields
• Send an email — Send an email to you, the assigned agent, the customer, a person in the workspace, or any email address — useful for internal alerts or notifying a third party
• Send CSAT survey — Trigger a CSAT survey delivery
• Send Trustpilot review invitation — Trigger a Trustpilot review invitation for the conversation/contact using the tenant’s Trustpilot AFS configuration. Delivery is handled through Trustpilot rather than by a direct Trustpilot API call

Both Send CSAT survey and Send Trustpilot review invitation take no configuration in the rule itself — their content and delivery settings live in Settings → CSAT Surveys and Settings → Trustpilot. Use Send CSAT survey when you want Atender to collect satisfaction feedback directly, and Send Trustpilot review invitation when you want the rule to trigger a Trustpilot review workflow instead. Trustpilot invitations require Trustpilot settings to be configured first.

For email conversations, Send auto-reply message uses the same auto-reply loop guard as Send email template and Send an email. Atender skips auto-generated messages, out-of-office replies, delivery status notifications, do-not-reply style bodies, and recipients that are over the hourly automation auto-reply cap. When a send is suppressed by this guard, Atender does not create a phantom sent message in the conversation timeline.

Notifications and chat

• Send notification to agents — In-app notification — to all agents, to the assigned agent, or to one named agent
• Send Slack message or DM — Post to a Slack channel, or send a direct message to an Atender user through their connected Slack account
• Add internal note — Append an internal note to the conversation (not visible to the customer)

Slack messages and DMs

Use Send Slack message or DM when an automation should alert people in Slack. The action can post to a Slack channel, or send DMs to Atender users whose Slack accounts are connected.

For DMs, choose recipients from the conversation context: the assigned agent, the people a comment mentions, or a named person. Recipient merge tags render separately for each DM recipient, so {{recipient.name}}, {{recipient.firstName}} and {{recipient.email}} use the details of the person receiving that DM. They resolve only on the DM path — in a channel post they have no value to fill in.

Conversation lifecycle

• Assign conversation to an agent or team — Set either the assigned team or a specific agent
• Update conversation status — Move the conversation between statuses (active, snoozed, done, archived)
• Resolve conversation (mark as done) — Mark Done
• Reopen conversation — Pull a Done conversation back into Active
• Add tag — Apply a tag. The tag must already exist — rules cannot create tags
• Remove tag — Strip a tag
• Set SLA policy — Attach an SLA policy to the conversation. The policies themselves are configured in Settings → SLA Policies. A policy set by this action stays when the conversation’s team or channel later changes
• Hand over to a human (turn off Agent Stack) — Route the conversation to a team and turn off the Agent Stack for it. This is one-way — the Agent Stack cannot be re-enabled on that conversation afterwards

Contact

• Set customer tier — Set the contact’s customer tier. Tiers are configured in CRM Settings → Customer Tiers first

Cases and tasks

• Assign case to an agent or team — Owner / team
• Change case stage — Move through the case workflow
• Close case — Mark closed
• Reopen case — Pull a closed case back open
• Set case priority — Low / normal / high / urgent
• Add tag to case — Tag at the case level
• Remove tag from case — Strip a case tag
• Link conversation to case — Coming soon — this action exists in the model but is unavailable in the action picker
• Create task — Create a task with a title and description

Three of these do nothing yet. Create task, Add tag to case and Remove tag from case are selectable in the action picker, and a rule using them reports success, but the engine logs “not yet implemented” and takes no action. Case tagging in particular has no column to write to. Don’t build a workflow that depends on them.

Eight of the case actions have no configuration form. The builder renders no fields for the Cases group, so values such as the target stage, the priority or the assignee cannot be set in the builder even where the server would read them.

Issues

• Change Issue status — Move the Issue to a status you pick from your Issue Tracker statuses. An Issue already in that status is left as it is
• Add label to Issue — Add one of your Issue labels to the Issue. Labels are added in Settings → Issue Tracker first. This changes the Issue, not the conversation
• Remove label from Issue — Remove an Issue label from the Issue
• Set Issue priority — Set the Issue’s priority, from your own priority list
• Set Issue type — Set the Issue’s type, from your own type list
• Assign Issue to a person — Assign the Issue to a person in the workspace, or pick Nobody (unassign)
• Add comment to Issue — Add a comment to the Issue. The reporter does not see it. The comment can use fields

The Issue actions are offered on the three Issue triggers — An Issue is created, An Issue changes and An Issue’s status changes — and on every conversation trigger except Run by hand. On a conversation trigger, the rule acts on each Issue the conversation is linked to, one run per linked Issue; a conversation with no linked Issue gives the Issue actions nothing to act on. When the Issue Tracker is off for the workspace, a rule on a conversation trigger that uses an Issue action or an Issue condition does not run at all.

The status you pick for Change Issue status comes from a dropdown of your current Issue Tracker statuses, so renaming a status in settings does not break a rule already built against it. Deleting the status does: the move then fails.

When the Issue moves, its history records the change and names the rule that made it: The rule “…” changed the status from … to …. The reporter is still told their report moved, exactly as when a person moves the Issue by hand: the default rules Tell the reporter their report moved (email) and (other channels) send that notice when they are on and the reporter reads the new status differently from the old one. The action has no setting to hold the notice back, so a rule that also sends its own message sends both.

Because the move is itself an Issue status change, one such rule can feed another. See the chase-and-close recipe for the pattern this action was built for.

External

• Send webhook to an external service — POST / GET / PUT / PATCH / DELETE to an arbitrary URL with templated headers and body — the universal escape hatch for systems Atender doesn’t natively integrate with
• Act on a tool dock — Send an event to one of your web-page tool docks on the conversation: Show a notice when an agent opens the dock, Open the dock for the next agent, or Send the event to the dock’s webhook. Docks are set up in Settings → Tool docks. A notice or an open reaches agents only where tool docks stand beside the conversation

Webhook action results are visible in the automation rules’ Run history tab. Each run is a row showing its status and a chip per action, with a failed action’s chip in red; a failed run’s error message appears beneath the row for debugging. For a failed call, the error message includes the start of the response body; Run history does not store the full request or response.

Flow control

• Wait — Pause the sequence for a delay before running the next action. Set a number and a unit — minutes, hours or days. Use for “send three hours after resolution” patterns.

Send an email

Send an email writes a plain email with a Subject and a body. In the recipient picker (Choose who gets it), choose who gets it:

• Me — You, the person who builds the rule
• Assigned agent — The agent assigned to the conversation when the rule runs
• Customer — The customer of the conversation
• A person — Any person in the workspace, from the People list
• An email address — Click Type an email address and type it, for example name@example.com

The rule cannot be saved until the email has a recipient, a subject and a body.

Fields in messages

Messages, emails, notes, notifications, Slack messages and webhooks can include fields — values that Atender fills in when the rule runs, such as the customer’s name or the conversation subject. A field shows as a chip in the text.

• Type / in the text, or click Insert field, to open the field menu.
• Search with plain words, for example “customer name” or “subject”.
• The menu offers only the fields that the rule’s trigger can fill.

Send email template — the most-used integration

Most workflows that send a templated email use Send email template rather than raw Send auto-reply message. The action picks a template by ID, and resolves the language — which chooses the template version — one of two ways:

• Match the customer — use the customer’s detected language first, then the language attached to the inbox or email channel, then fallback languages such as English or the template default when no matching version exists.
• A specific language — pick one of the template’s languages from the list.

The rendered HTML carries an X-Email-Template header so you can see which template produced any given message in delivery logs. Fields inside the template ({{contact.name}}, {{conversation.subject}}, custom fields) fill at send time from the conversation context.

Webhook templating

The webhook body is entirely yours — Atender sends what you write, with no payload of its own wrapped around it. The URL, the header values and the body all take fields, the same as messages. A typical payload:

{
  "conversation_id": "{{conversation.id}}",
  "subject": "{{conversation.subject}}",
  "customer": "{{contact.name}}",
  "customer_email": "{{contact.email}}",
  "amount": "{{custom.refund_amount}}"
}

Insert fields from the field menu rather than typing them from memory. Things to know before you rely on one:

• There are no {{case.*}} or {{tenant.*}} merge tags. Cases are available to automations as conditions and as actions, not as merge tags, and the tenant slug is never exposed as one. A tag that does not exist is not an error — it ships to your endpoint as the literal text {{case.id}}.
• Custom fields are {{custom.<fieldKey>}}, using the field’s key. There is no custom_fields path.
• {{links.csat_survey_url}} and {{links.unsubscribe_url}} do not resolve in an automation. The automation field menu does not offer them, because the automation engine has no substitution for them: typed into a rule, they ship as literal text. They work only in Email Studio templates. Send a survey with the Send CSAT survey action instead of hand-building a link.
• Content-Type: application/json is added for you on every non-GET request, and a handful of hop-by-hop and forwarding headers are stripped if you set them.
• In a webhook — URL, headers or body — {{conversation.id}} resolves to the raw UUID rather than the human-readable conversation ID, because the receiving system needs the stable key.

A non-2xx response or a transport error fails the action and the run is attempted up to three times with exponential backoff; actions that already completed are not re-run. The default timeout is 30 seconds, configurable from 1 to 120. URLs pointing at localhost, link-local or private address ranges are refused.

The webhook action records the call result in Run history with the run status, action chip, and any retained failure message — useful for debugging downstream failures.

Wait — and why some recipes need it

The Wait action pauses the sequence for a configurable delay. When the delay expires, Atender resumes the sequence at the next action. In a branch with conditions, Atender checks the conditions again first, with fresh data; if they no longer match, the remaining actions are skipped. Use for:

• Three-hour gap before sending a CSAT survey
• 14-day gap before archiving inactive Done conversations
• 24-hour gap before sending a follow-up “anything else?” template

Waits are persisted; if Atender is restarted mid-wait, the action resumes correctly.

Escalation side-conversation safety

On escalation side conversations, Atender allows internal actions such as Add tag, Remove tag, assignment, priority and status changes, notes, in-app notifications, and case updates. Atender skips external or outbound actions in that context. The blocked set is exactly seven: Send auto-reply message, Send WhatsApp template, Send an email, Send email template, Send CSAT survey, Send Slack message or DM and Send webhook to an external service.

An Act on a tool dock step that sends the event to the dock’s webhook is skipped there too; its notice and open events still run.

Send Trustpilot review invitation is not in that set — it still runs on an escalation side conversation. If that is not what you want, gate it on a condition rather than relying on the escalation guard.

This protects against accidental outbound delivery while preserving internal workflow actions and reporting tags.

See also

• Trigger types reference
• Conditions and operators reference
• Recipes — see how these actions combine in real rules