Automation
Automation lets the people who use your agent ask it to do a piece of work later, on its own, without opening the conversation again. Someone says "Every morning at 8, check the SLA of all branches. If any is below 80%, find out why and send the result to my WhatsApp" — and from then on the agent does exactly that, every day, in the background.
Nobody has to learn cron expressions, queues or workflow builders. The conversation is the interface; Automation is the persistent execution.
The model in one line
Every automation follows the same four steps:
Trigger → Condition → Task → Action
| Step | Answers | Example |
|---|---|---|
| Trigger | When is it evaluated? | Every day at 08:00 (Asia/Jakarta) |
| Condition | Should it carry on? (optional) | SLA is below 80% |
| Task | What work does the agent do? | Analyze the SLA and find the likely causes |
| Action | What happens with the result? | Send a WhatsApp message to 0812… |
The task runs in your agent's own context — with its configuration, skills, and data access — and never with more permission than the person who created the automation already has.
Who does what
Two groups of people are involved, in two different places:
| Who | Where | What they do |
|---|---|---|
| Users of your agent | The chat itself, and the Automations page in QA-Web | Create automations by talking to the agent, then view, edit, pause, resume, run now, view history of, and delete their own. |
| You — the agent's Owner or Contributor | The Automations group in the CMS sidebar | Decide whether users may automate anything and within which limits (Policy), and watch or govern what they created (Monitor). |
You govern; you do not write your users' automations for them. What an automation does stays with the person who asked for it.
Where it lives in the CMS
Open your agent's sidebar. Between Channels and Simulation there is an Automations group with two pages:
| Page | What it is for | Guide |
|---|---|---|
| Policy | The master switch and every limit: what users may automate, how many, how often, and what they may do with their own automations. Off by default. | Set Up the Automation Policy |
| Monitor | A governance view of every automation users created on this agent, with run history and pause / resume / disable / delete. | Monitor and Govern |
In this section
| Guide | What you will learn |
|---|---|
| How Automation Works | The life of an automation: creation, scheduling, a run, the result, and the statuses in between. |
| Set Up the Automation Policy | Switching Automation on and choosing the limits. |
| Create an Automation | What your users say, what the agent shows back, and how to confirm — including schedules, conditions and actions. |
| Manage Your Automations | The user's own view: the Automations page, notifications, and the controls on each automation. |
| Monitor and Govern | The CMS Monitor, contributor permissions, and how Privacy Mode changes what you can see. |
| Troubleshooting Runs | Why a run was skipped, failed, or an automation stopped — and what to do about it. |
Before you start
- Users must be signed in. An automation belongs to a person, so it can only be created and managed by someone who is logged in. Visitors, the CMS preview, group chats and agent-to-agent calls never get Automation.
- It is off until you switch it on. Until you enable it on the Policy page, the agent does not offer Automation and nobody sees an Automations entry in the chat.
- Every run spends credit. A run is a real turn of your agent, billed like any other conversation. The Policy page has limits to keep this predictable.