Atender — Automations, where things actually get done.

The shape

Anatomy of an automation

The shape is always the same; only the contents change. Every automation answers four questions in order: when does it wake up, does this situation apply to me, which path do I take, and then what do I do.

1The four parts — in the order the engine evaluates them

↯

Trigger

The event that wakes the rule up. Exactly one per automation.

◇

Conditions

Filters that decide whether this run is one we care about.

⊲

Branches

If / else-if / else paths so one rule handles many situations.

▶

Actions

The verbs. Each branch runs its actions in order, top to bottom.

Each part has its own surface in the builder ↓

2Triggers — more than thirty events the engine can listen for

In the builder

Select an event… ▾

Conversation6

Message3

Tags2

Cases6

Customer tiers3

Time-based6

Side conversations2

Comments & mentions2

Contact2

Manual1

A few concrete events — this is not the full set

Conversation created Message received Tag added SLA breach warning Conversation resolved Customer tier changed Scheduled (cron) Business hours started

+ 25 more events

Triggers come from across the product — conversation lifecycle, tags, cases, SLAs, customer tiers, schedules, business hours, side conversations, mentions. Each trigger sets the type of context the rest of the rule works with.

3Conditions & branches — if / else-if / else, with nested AND/OR groups

Always no condition

Runs every time the rule fires

Use for setup work that should happen on every match — tagging the conversation as touched, logging an audit note, kicking off a webhook.

If condition group

Runs when its condition group is true

Conditions can be nested arbitrarily deep with AND/OR, against fields on the conversation, contact, message, case, custom fields, and event-specific fields like previous status.

Else if cascading

The next path the engine tries

Lets one automation handle many cases without forking. If VIP escalate; else-if billing route to billing; else default reply.

Else fallback

Runs when nothing above matched

Catches anything that didn’t fit a specific branch. The default-behaviour slot.

One trigger, many branches. A single automation often handles five or six different situations — the trigger picks which conversations come in, branches sort them into paths, and each path runs its own actions. The alternative — one rule per case — turns into a thicket fast.

The verbs

What an automation can actually do

Actions are the verbs — about two dozen of them. They cluster naturally around a handful of stems: send something, add or remove something, assign or set something, resolve something, or reach outside Atender entirely. Most of the apps you already use in the product show up here as targets of these verbs.

1The vocabulary, by verb — each row is one verb stem; the chips are what you can do with it

Send

message on the channel Email Studio template external email Slack message CSAT survey agent notification

Add · remove

tag case tag internal note

Assign

agent team case owner

Set

conversation status case stage case priority customer tier

Resolve · reopen

conversation done conversation reopened case closed case reopened

Link · create

conversation → case task

Reach out · wait

webhook (any URL) wait / delay

The Email Studio bridge. Send Email Studio template is the most-used action in the whole catalogue, and it’s the seam where two systems meet: a designer builds the template visually in Email Studio; an automation picks it up by ID, resolves the language from the channel, fills the merge tags, and sends. Either side without the other is half the story.

The webhook is the universal escape hatch. When there’s no built-in action for what you need — a finance system, an internal service, a third-party SaaS — the webhook calls it directly. POST, GET, PUT, DELETE, with templated headers and body. If you can describe the request, the webhook can make it.

Day-to-day

How you build, ship, and watch one

There are two ways to get an automation built, three controls to shape how it runs once it’s live, and a full execution history when you want to know what actually happened.

1Two ways to build one — pick the one that matches what you already know

Manual visual builder

Drag, drop, configure

The visual editor where you assemble triggers, conditions, branches, and actions by hand. Best when you know exactly the shape you want, or when the rule is intricate enough that you want to see every node laid out.

AI describe in English

Describe the outcome

“When a customer emails us, send the order confirmation in their own language.” The AI assembles a draft rule from the description; you review the structure, adjust anything you don’t love, and activate it.

2And one way to understand an existing rule — for the ones you didn’t build, or built six months ago

Explain Rule AI readout in plain language

What does this automation actually do?

Pick any rule — yours, a teammate’s, an inherited one — and the AI describes what it does in plain English. The inverse of the AI builder. Useful for audits, onboarding new teammates, and the inevitable “why did this happen?” moments after a rule has been running quietly for months.

Once it’s built, four controls shape how it runs ↓

3Operational controls — the dials you turn after a rule is live

Enable / disable

Pause without deleting

Every rule has an on/off toggle. Disabling preserves the rule and its history; you don’t have to delete to stop it.

Schedule business hours

Only inside, only outside, or anytime

Scope a rule to run only during business hours, or only outside them. After-hours auto-replies, in-hours auto-routing, and anything that should behave differently when the team is or isn’t around.

Throttle N runs / M minutes

Rate-limit how often it fires

Per conversation, per contact, or globally. Stops a chatty webhook trigger from running ten times in a row, or the same customer from getting five CSAT surveys in a week.

Manual run simulate → execute

Trigger a rule against historical data

Two-step on purpose: simulate evaluates which conversations match without running any actions, then execute processes the confirmed list. The split exists because actions can be irreversible — sending email, closing cases, firing webhooks — and you want to look before you fire.

Throttling is the difference between an automation and a runaway script. The default action of any newly-built rule is “run every time the trigger fires,” which is almost never what you actually want. Set the throttle deliberately, especially on rules that send messages to customers or call out to other systems.

And while it runs, the audit trail ↓

4Execution history — what happened, in detail

Every run is recorded

For each execution: when it fired, what triggered it, which branch matched, which actions ran, whether each one succeeded or failed, and the input/output payload at every step. Filter by failure to find the rules that aren’t doing what you think they are — the engine will keep firing them silently until you go look.