How Automation Works
This page follows one automation from the moment a user asks for it to the moment they read the result — and explains the statuses you will meet along the way.
1. A user asks
Automations are created in conversation — in the web chat, in a voice call, or on WhatsApp. The user just describes what they want:
"Every morning at 8, summarize yesterday's sales for me."
"Tomorrow at 9, remind me about the board meeting."
"Every Monday at 7, check inventory in all warehouses. If anything is below the minimum, analyze it and create a conversation for me."
The agent works out the trigger, condition, task and action from those words. It does not create anything yet.
2. The agent shows its interpretation
Before anything is saved, the agent shows a summary for the user to check — Trigger, Condition, Task, Skills, Action, the next three times it will run, any policy warnings, and (for WhatsApp) the recipient number written out in international format, such as +62 812…. Anything ambiguous can be corrected here.
The user confirms with a plain "yes", and only then is the automation created. The pending summary expires after 30 minutes. See Create an Automation.
3. It is scheduled
Qlar stores the automation and schedules only its next run — not a timer per automation. After a run, it calculates the following one and schedules that. Editing, pausing or deleting an automation cancels what was scheduled, and a run that arrives for an automation that has since changed is discarded rather than executed.
Runs may begin up to a minute or so after the scheduled time. Qlar spreads automations that share a popular time (like 08:00) so they do not all start in the same second. When many are due at once they queue and run in order, so a busy moment can delay a run further.
4. The run
When a run is due, Qlar checks that the automation is still active and still allowed by the policy, then runs one turn of your agent in a new conversation, as the user who created it:
- If the automation has a condition, the agent first reads the current data with its own tools and reports the values. Qlar evaluates the rules itself. If the condition is not met, the run stops here — no conversation, no message.
- Otherwise the agent carries out the task.
- Qlar then performs the actions: a new conversation and/or a WhatsApp message.
During a run the agent has no way to escalate to a human, and it does not write to the person's memory. Skills the user selected when creating the automation are attached to the run.
5. The result
| Action | What the user gets |
|---|---|
| Create conversation | A new conversation appears in their list, marked unread and marked as written by an automation, and a notification appears on the bell. They can open it and keep chatting like any other conversation — the agent knows which automation produced it. |
| Send WhatsApp message | The result is sent to the number in the automation. |
Conversations from runs that failed, whose condition was not met, or that only send WhatsApp never appear in the user's list.
Statuses
An automation is always in one of five statuses:
| Status | Shown to users as | Meaning |
|---|---|---|
| Active | Active | Running on its schedule. |
| Paused | Paused | Stopped for now. Paused by the user, by a contributor, because the user has more active automations than the policy now allows, or because the agent moved to another organization. |
| Disabled | Turned off | Switched off by a contributor. The user cannot resume or edit it, but can still delete it. |
| Error | Stopped | Stopped automatically — after three failed runs in a row, or because the policy or the user's access no longer allows it. |
| Completed | Finished | It has no future runs: a one-time automation that ran, or one that reached its end date or maximum number of runs. Removed after 7 days. |
Every status carries a reason, shown on the automation in both the CMS Monitor and the user's Automations page. See Troubleshooting Runs for the full list.
Run outcomes
Each run is recorded in the automation's history:
| Outcome | Meaning |
|---|---|
| Succeeded | The task ran and the actions were performed. |
| Condition not met | The condition was checked and did not hold, so nothing was done. This is normal, not a failure. |
| Failed | The run could not finish. Temporary failures are retried according to the policy; three failures in a row stop the automation. |
| Skipped | The run was not attempted — for example the policy is off, or a daily limit was reached. |
| Timed out | The run took longer than the policy's run timeout. |
| Interrupted | The run was cut off before it finished. |
What is remembered, and for how long
| Data | Kept |
|---|---|
| The automation | As long as it has future runs. Finished ones are removed after 7 days; paused, stopped or turned-off ones nobody has touched for 90 days are cleaned up; a user deleting one removes it at once. |
| Run history | For the policy's History Retention (default 30 days). Records when it ran and how it ended — never the answer itself, which lives in the user's conversation. |
| Notifications | 30 days. |
If the organization uses Privacy Mode, the content of every automation is encrypted. See Monitor and Govern.