Set Up the Automation Policy
Open in CMSThe Policy page decides whether the users of your agent may set up automations at all, and within which limits. It is where you keep Automation predictable: how many automations a person can have, how often they may run, and how much they may cost.
Navigate to Automations → Policy in the left sidebar.
Decide whether the users of this agent may set up automations — tasks the agent runs on a schedule for them — and within which limits. Saved changes apply at once, without publishing the agent.
Switch it on
The first card holds the master switch: Let users create automations on this agent.
| State | What happens |
|---|---|
| Off (default) | The agent offers no automations, and users see no Automations entry in the chat. Automations that already exist are skipped when they fall due — nothing is deleted. Users can still pause or delete what they have. |
| On | Users can ask the agent to run a task on a schedule and deliver the result as a new conversation or a WhatsApp message. |
Switching it off is a safe way to stop everything at once: the automations stay, and they carry on the day you switch it back on.
Saved changes take effect immediately — there is no need to publish the agent. At the bottom of the page a status line tells you whether the conversation service has received the latest policy. If it says it has not, press Resend.
What users may automate
| Setting | What it does |
|---|---|
| Allowed Triggers | Which kinds of trigger are allowed. Only Time (schedules) is available today; event triggers are not available yet. |
| Minimum Interval (minutes) | The shortest gap allowed between two runs of the same automation, from 5 to 10080 (one week). Default 15. |
| Allowed Actions | How a result may reach the user: Create conversation and/or Send WhatsApp message. At least one must stay allowed. |
| Maximum WhatsApp Messages per Day | For all of this agent's users together, from 1 to 5000. Default 100. It protects the shared WhatsApp numbers from being blocked, and only applies while WhatsApp is an allowed action. |
WhatsApp messages go to the number the user gives, from the platform's shared numbers.
Limits per user
| Setting | What it does |
|---|---|
| Maximum Active Automations | How many one user can have running at the same time, from 1 to 100. Default 10. Lowering it pauses the newest automations above the new limit; the oldest keep running. |
| Maximum Total Automations | Active and paused together, up to 200. Default 20. It cannot be lower than the number of active ones. Finished automations do not count. |
| Maximum Runs per User per Day | All of one user's automations on this agent together, from 1 to 1000. Default 100. Every run spends credit. |
| Maximum Runs per Automation | How many times one automation may run before it is finished. 0 means no limit. Up to 100000. |
Running
| Setting | What it does |
|---|---|
| Run Timeout (seconds) | How long one run may take, from 60 to 900. Default 300. |
| History Retention (days) | How long run history is kept, from 1 to 365. Default 30. |
| Maximum Retries | Retries after a temporary failure, from 0 to 5. Default 2. A WhatsApp message is never sent twice. |
| Retry Interval (minutes) | The wait before a retry, from 1 to 1440. Default 5. |
What users may do
Six switches, all on by default, decide what people may do with their own automations:
| Switch | What it allows |
|---|---|
| Create automations | Off stops new automations; existing ones keep running. |
| Edit automations | Change the schedule, task, condition, actions or recipient. |
| Delete automations | Off leaves users only able to pause. Owners and Admins can still delete from the Monitor. |
| Pause and resume | Stop an automation for a while and start it again. |
| Run now | Run an automation immediately instead of waiting for its schedule. |
| View history | See when each automation ran and how it ended. |
These switches limit users, not you. Contributors govern every automation from the Monitor, whatever is set here.
A policy is checked twice
The policy is validated when an automation is created or changed, and again every time it runs. So a tighter policy binds automations made under a looser one:
| You change… | Existing automations… |
|---|---|
| Minimum Interval to something longer | That run more often than the new minimum are stopped with a clear reason. |
| Allowed Actions, removing one | Lose that action. If nothing allowed is left they are stopped. |
| Maximum Active Automations to a lower number | Have the newest ones above it paused. |
| The master switch to off | Are skipped when due. Nothing is deleted. |
Users see the reason on the automation, so a stopped automation never fails without explanation. See Troubleshooting Runs.
Starting points
There is no single right setting, but these are sensible places to begin:
| Situation | Suggestion |
|---|---|
| Trying it with a few colleagues | Leave the defaults, keep WhatsApp allowed, and lower Maximum Runs per User per Day until you see how it is used. |
| Cost-sensitive agent | Raise Minimum Interval (for example to 60 minutes), lower Maximum Active Automations, and set Maximum Runs per Automation. |
| Agent that must not message outside Qlar | Allow only Create conversation. |
| Agent whose data changes slowly | Set Minimum Interval to a day (1440) — nobody needs an hourly check of a daily figure. |
Next step
Once the policy is on, users can start creating automations — see Create an Automation. To see what they create, open the Monitor. For a compact list of every field, see Help → Policy.