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.
In this tutorial you switch Automation on for Atlas, Kirana Group's operations assistant, so that project managers and the operations lead can ask Atlas to check projects for them on a schedule. You keep the default limits, which suit a first rollout.
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.
Before you start
- You are an Owner or Contributor of the agent.
- You know how an automation runs. See How Automation Works.
- Your users can sign in to the agent. Automation is only offered to signed-in people; see Manage Who Can Use and Build.
- The agent can already read the data people will want checked. Atlas reads project status through its Projects API; see Connect Your API.
Step 1: Switch it on
The first card holds the master switch: Let users create automations on this agent. Turn it on. The description below it reads: "Users can ask the agent to run a task on a schedule and deliver the result as a new conversation, a WhatsApp message or an email."
| 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, a WhatsApp message or an email, as far as Allowed Actions permits. |
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.
Step 2: Choose what users may automate
The What Users May Automate card sets the kinds of automation people can create. For Atlas, keep the values shown.
| 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 reaches the user: Create conversation, Send WhatsApp message and/or Send email. 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 this agent's WhatsApp number from being blocked, and only applies while WhatsApp is an allowed action. |
| Maximum Emails per Day | For all of this agent's users together, from 1 to 5000. Default 100. It protects the sending domain from being marked as spam, and only applies while email is an allowed action. |
WhatsApp messages go to the number the user gives, from this agent's own WhatsApp number: the channel on the public or private server in its Published configuration (see Connect to WhatsApp). Meta Cloud, Coster and Qontak can only start a conversation with an approved message template, so they cannot send automation results. While WhatsApp is allowed and the Published configuration has no channel that can send, the card shows a warning under these fields. A project manager could, for example, have a daily summary sent to a site supervisor's phone.
Emails go to the address the user gives, or to their own account's address if they give none, from this agent's automation address {agent}-automation@qlar.ai under the agent's name; for Atlas that is atlas-ops-automation@qlar.ai. There is nothing to connect. Nobody reads that mailbox, so the email links back to the user's Automations page in Qlar instead. On top of the daily limit, a user's automations may send at most 10 emails an hour to one address. See Actions, WhatsApp and Email.
Policies saved before email existed do not allow it. If this agent's policy was saved before Send email was added, the option is unticked, and the agent tells users that email is not available. Tick Send email under Allowed Actions and click Save to offer it.
Step 3: Set the limits per user
The Limits per User card keeps one person from creating more than you want to pay for. Keep the defaults for Atlas.
| 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. |
Step 4: Set how runs behave
The Running card controls a single run.
| 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 or email is never sent twice. |
| Retry Interval (minutes) | The wait before a retry, from 1 to 1440. Default 5. |
Step 5: Decide what users may do
The What Users May Do card has six switches, all on by default. They 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.
Step 6: Save
Click Save. The CMS confirms: "Automation policy saved. It applies to this agent's users right away — no publish needed."
Saved changes take effect immediately, so 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.
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 (for example the Atlas pilot with the operations team) | Leave the defaults, keep WhatsApp and email 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). Project status that is updated once a day does not need an hourly check. |
Check the result
- Reload the Policy page. Let users create automations on this agent is still on, and the cards show the values you saved.
- Open Atlas's public chat (QA-Web) and sign in. Open the sidebar with ☰: an Automations entry is now there.
- Ask Atlas for an automation, such as "Every weekday at 7:30, check the status of project KG-2041 and give me a short summary, but only if it is delayed or on hold." Atlas answers with an automation preview instead of saying it cannot do this. The CMS preview never offers Automation, so test in the public chat.
Next steps
- Next in the journey: Create an Automation. Once the policy is on, users can start creating automations.
- Monitor and Govern: see what users create.
- Help → Policy: a compact list of every field.