AI Automation Builder
proLet managers automate routine work with scheduled and event-triggered, approval-guarded actions.
The AI Automation Builder turns the checks you run by hand — "did last week's revenue drop?", "is any site low on stock?", "tell me the moment a big sale lands" — into automations that watch your live data and report (or act) on their own. Each automation is one definition: a trigger, an optional alarm condition, a delivery method, and an optional guarded action. Because it reads the same datasets that power Analytics & Data Explorer, an automation always works from current numbers — there is nothing to export or reconcile.
The Builder lives inside the AI Assistant (Copilot) module on the AI page. The chat copilot, proactive insights, and the four built-in routines are covered in the AI Assistant guide; this page is the deep dive on building, scheduling, and governing your own automations.
The Builder is part of the AI Copilot & Automations module. If you do not see the AI page in the sidebar, that module is not enabled for your organization — your Apolaris contact can turn it on.
Who can do this
Every Builder mutation and run is gated by the same rule the code calls "always a manager": the endpoints require the assistant module and that the signed-in user is a domain manager (is_manager).
| Action | Who can do it |
|---|---|
| View existing automations (read-only) | Any user with the AI module |
| Create, edit, delete, toggle, run, clone an automation | Managers only (is_manager) |
| Draft an automation with AI / get suggestions | Managers only |
| Run a live preview | Managers only |
| Approve or reject a staged action | Managers only |
| Export an automation's full definition | Any user with the AI module |
There is no separate "automation" privilege. The Builder is intentionally manager-only — non-managers cannot configure, run, or approve automations even if they can open the AI page. A privilege admin (can_manage_privileges) who is not a manager does not gain Builder access.
Anatomy of an automation
Every automation is a single definition with these parts:
| Part | What it does |
|---|---|
| Trigger | When it runs — on a schedule, when something happens (an event), or manually |
| Data source | What it looks at — a Data Explorer data query, a built-in routine, or the business snapshot |
| Condition (alarm) | Optional. When a metric crosses a threshold. No condition = a pure report that runs every time |
| Delivery | How you hear about it — in-app notification, emailed report, and/or a raised in-app insight |
| Action | Optional. A follow-up the automation performs when it fires — always behind guardrails |
A run with no condition is a report (it always delivers if you ask it to). A run with a condition is an alarm that only flags when the threshold is crossed.
Triggers
| Trigger | Meaning | Configuration |
|---|---|---|
| On a schedule | Runs on a cadence | Frequency = hourly, daily, weekly, or monthly, plus the hour/minute (and weekday or day-of-month where relevant) |
| When something happens | Runs the moment a record changes | An event key (see below), an optional filter on the event's fields, and a throttle (minutes between re-fires) |
| Manual only | Runs only when you click Run, never on its own | — |
Scheduled times use your organization's time zone and default language, so reports read the way your team reads them.
Event triggers
Event automations fire in real time from a record change. The available events depend on which modules your organization has enabled (for example, contact-center and camera events only appear when those modules are on):
| Event key | Fires when | Fields you can filter on |
|---|---|---|
sale.created |
A sale is recorded | Amount, payment status, tip |
booking.created |
An appointment is booked | Service, price, site |
booking.cancelled |
An appointment is cancelled | Service, site |
booking.no_show |
A no-show is recorded | Service, site |
customer.created |
A new customer is added | Lifetime spend |
leave.requested |
A leave request is created | Days, status |
expense.created |
An expense is logged | Amount, category, status |
conversation.created |
A new contact-center conversation starts (requires CCaaS) | Status, handled-by |
payment.paid |
A contact-center payment is paid (requires CCaaS) | Amount, tip |
camera.alert |
A camera alert is raised (requires Cameras) | Event type, confidence |
Event triggers run asynchronously so the action that caused them (saving a sale, booking an appointment) is never slowed down or blocked. There are built-in cost guards: an automation's own writes cannot re-fire events (no loops), the same record cannot re-fire the same automation twice, your per-automation throttle is respected, and there is a hard per-organization hourly cap on event-triggered runs.
Data sources
| Source | Use it for |
|---|---|
| Data query | The flexible option — any Data Explorer dataset (sales, bookings, inventory, expenses, leave, and more) with the same measures, dimensions, filters, and date window |
| Built-in routine | One of the four shipped routines (camera daily review, payment-process verification, automatic business report, payroll pre-check) |
| Business snapshot | A ready-made daily summary of sales, bookings, low stock, and pending leave |
Because the data query source is just a saved Data Explorer query, the two tools share one vocabulary: a measure, dimension, or filter you can build in the Explorer is the same one an automation watches.
Conditions (the alarm)
A condition turns a report into an alarm. Pick a condition type, a comparison, and a value:
| Condition type | What it measures |
|---|---|
| Row count | How many rows the query returns (e.g. "1 or more pending leave requests") |
| Measure | A measure aggregated across the result — sum, average, max, or min (e.g. "minimum units in stock below 5") |
| Percent change | How much a measure moved versus the previous window (e.g. "revenue down more than 20% vs last week"). Set the window length and the comparison window in days |
Comparisons are greater / greater-or-equal / less / less-or-equal / equal / not-equal. For a drop alarm, use percent-change with a negative value and a "less than" comparison.
Leave the condition empty when you just want a recurring report. Add a condition only when you want to be alerted on a threshold — that is the difference between "email me Monday's numbers" and "email me only if Monday's numbers fall."
Build an automation step by step
- Open the AI page and go to the Automations area, then start a new automation.
- Give it a name, optional description, and icon.
- Choose a trigger — schedule, event, or manual — and configure its timing/event.
- Choose a data source — a data query, a built-in routine, or the business snapshot. For a data query, pick the dataset, measures, dimensions, filters, and date range.
- Add an optional condition (alarm) with a comparison and threshold.
- Choose delivery: in-app notification, emailed report (PDF, Excel, CSV, Word, or full-detail JSON), and/or a raised insight. Pick who is notified — managers, just you, or specific people — and whether to deliver every run or only when the alarm fires.
- (Optional) Add an action — see Actions.
- Run a live preview (see below) to confirm the result and whether the alarm would fire.
- Save. A scheduled automation immediately gets its next run time computed.
Deliver only when the alarm fires for watchdog automations (you only want to hear about problems), and every run for routine reports you want on a fixed cadence.
Draft an automation with AI
You do not have to assemble all of that by hand. Describe what you want in plain language — for example, "warn me when a site sells 20% less than last week" or "email the managers an Excel report every Monday morning of last week's revenue by site, and open a task when it fires" — and the Builder drafts a complete configuration for you: the data source (a data query, a built-in routine, or the snapshot), the measures, the alarm, the schedule down to the weekday or day of the month, who hears about it and in which format, and the follow-up action where you asked for one.
Drafting runs in the background with a progress bar, so it has room to work through the whole configuration rather than returning whatever fits in a few seconds. You can keep using the page while it runs, and Cancel at any point. When it finishes, the Builder opens pre-filled — review the draft, adjust any field, then save.
You can also ask the Builder for suggestions: it proposes a handful of useful automations tailored to which modules your organization has on (revenue-drop alert, daily summary, no-show watch, low-stock watch, pending-leave nudge, monthly expense budget, and similar).
AI drafting and suggestions degrade gracefully. If no AI backend is configured, the Builder still drafts a sensible starting point from keywords in your request and labels it clearly so you know to review every field. The draft is always re-validated against the Data Explorer's allowed datasets and fields before it can be saved, so an AI draft can never smuggle in a data source you are not allowed to query.
A drafted action is still held for approval. The drafter is not permitted to turn that guardrail off — switching an action to run on its own is always a decision you make yourself, in the Builder. See Actions and the approval gate.
What this will do
At the top of the Builder, and on every automation card, is one sentence saying what the automation will actually do — read from the settings themselves, not written by the AI:
Every Monday at 08:00, it checks revenue in sales by site over the last 7 days, and alerts when the change is < -20%. You get an in-app notification + an emailed PDF report — the managers, when the alarm fires. Then it prepares "Send an email campaign" and waits for your approval.
It updates as you edit, which is the quickest way to confirm that an AI draft — or a field you just changed — means what you think it means.
Delivery, actions and the finer schedule detail sit behind Delivery, action and fine detail so the form opens at the handful of choices that differ between most automations. Everything is still there; it is one click away.
Preview before you save
Run a live preview at any point to see exactly what the automation would produce against your current data — the narrative summary, a sample of the result rows, the computed metric, and whether the alarm condition would fire. The preview is completely safe: it does not save a run, does not deliver anything, and does not run any action. Use it to tune your threshold before going live.
Delivery options
| Setting | Options |
|---|---|
| In-app notification | On/off |
| Email a report | On/off; attach as PDF, Excel (.xlsx), CSV, Word (.doc), or JSON (full detail) |
| Raise an insight | On/off; with a severity of Info, Warning, or Critical |
| Recipients | Managers, only me, or specific people |
| When to deliver | Only when the alarm fires, or every run |
When recipients is Managers, the automation notifies domain managers (and users who can approve leave). Email goes to the comma/space/newline-separated address list you provide.
Actions and the approval gate
An automation can do more than report — it can perform a follow-up action when it fires. Actions are heavily guarded.
| Action | Outward-facing? | What it does |
|---|---|---|
| Create a task / staff alert | No (internal) | Sends a task/alert notification to managers |
| Email a customer | Yes | Emails the customer named on the triggering event, or a fixed address |
| Message a customer (contact center) | Yes | Sends a contact-center message to the event's customer |
| Call a webhook | Yes | POSTs a JSON payload to an external URL |
How an action runs is decided every time it fires:
- Dry run — if you enable dry-run on the automation, the action only computes a human-readable preview and performs nothing. Use this to see exactly what an action would do before you let it loose.
- Approval queue — every outward-facing action (email a customer, message a customer, call a webhook) is always staged for manager approval before anything leaves the building, no matter how the automation is configured. Internal actions are also queued when you keep "requires approval" on (the default), or whenever the run was not started by an interactive user (for example, a scheduled or event run).
- Auto-execute — an action runs immediately only when it is an internal action, "requires approval" is turned off, and a person triggered the run.
An approved action mutates live data with the same consequences as doing it by hand — an emailed message really sends, a contact-center message really goes to the customer, a webhook really fires. The approval queue is the safety gate. Read the preview before approving, and remember the action's effects ripple downstream just like manual changes: a sale touches inventory, loyalty, and Analytics; a customer message reaches a real person. Treat approval as a deliberate decision, not a rubber stamp.
The approval queue
- When an automation's action is staged, every manager (and leave-approver) gets a notification: "Automation action needs approval."
- Open the Automations area on the AI page and review the pending approvals. Each shows a human-readable preview of exactly what will happen.
- Approve to carry the action out now, or reject to discard it. Only on approval does the action actually run.
- Staged actions expire after 7 days if no one decides on them.
Built-in safety rails apply to every action: it runs in a guarded context so its own writes cannot re-trigger event automations (no loops), and a webhook is blocked from reaching internal, loopback, private, or metadata addresses — only public http(s) URLs (optionally an allowlist your operator configures) are allowed.
Running and scheduling
- Manually: open the automation and click Run. The result is recorded immediately and you can read it on the spot.
- On a schedule: this stack has no always-on background worker. Scheduled automations are driven by the operating system's scheduler (Windows Task Scheduler or cron) calling the
run_automationsmanagement command on a tight cadence — typically every 15 minutes, which serves hourly, daily, weekly, and monthly automations alike. Each automation advances its own next-run time. - On an event: nothing to schedule — the automation fires the moment a matching record changes.
The scheduler cadence is part of your deployment's setup (managed by your Apolaris contact for hosted organizations). If a scheduled automation never seems to run, the OS scheduler driving run_automations is the thing to check. A single broken automation can neither block the batch nor re-fire every cycle — failures are recorded on the run and the next-run time always advances.
Where to see results
Every run — manual, scheduled, or event — is recorded with its status (done, issues, or failed), the AI-written summary and full report, the computed metric, whether the alarm fired, what was delivered, and any action result. Open an automation to read its run history (the most recent runs). You can also export an automation's full definition in CSV, Excel, PDF, Word, or JSON for backup or to recreate it elsewhere.
Built-in routines and cloning
The four shipped built-in routines appear as read-only example automations you can inspect in full:
- Camera daily review — yesterday's camera activity per site (requires Cameras)
- Payment process verification — completed appointments with no recorded sale, and charges that deviate from list prices
- Automatic business report — a daily narrative snapshot of sales, bookings, per-site revenue, stock, and HR queues
- Payroll pre-check — verifies the latest payroll period for missing entries, zero/negative net pay, and upcoming approved leave
You cannot edit or delete a built-in, but you can clone any automation (including a built-in) into a new, editable copy that you own — then change its schedule, add a condition, or change delivery. The original stays intact.
The fastest way to learn the Builder is to clone a built-in routine and add a condition to it, rather than designing a data query from scratch.
Examples
Weekly revenue-drop alert. Trigger: schedule, weekly. Source: a sales data query grouped by site over 7 days. Condition: percent-change of revenue, less than -20, comparing this week to last. Delivery: email a PDF to managers, only when the alarm fires. Result: a Monday email lands only if a site fell more than 20%.
Low-stock watch. Trigger: schedule, daily. Source: an inventory data query grouped by site. Condition: measure = minimum units, less than 5. Delivery: in-app notification to managers every time it fires. Result: a daily heads-up before you run out.
Big-sale alert with a guarded thank-you. Trigger: event sale.created with a filter "amount greater than 5000". Action: email the customer a thank-you. Because emailing a customer is outward-facing, the email is staged for approval — a manager sees the exact draft and approves before it sends.
Pending-leave nudge. Trigger: schedule, daily. Source: a leave data query filtered to status "pending". Condition: row count, greater-or-equal 1. Delivery: a raised insight. Result: a daily reminder while requests wait for a decision.
Edge cases and warnings
Actions change real data. A report is read-only, but an action — especially an outward-facing one — has the same effect as doing it by hand. The approval queue exists so a human signs off before anything customer-facing or external happens. Never disable "requires approval" on an action you have not previewed and tested.
A condition's threshold needs prior data. A percent-change alarm cannot compute without a comparable previous window, so it simply will not fire when there is no prior data to compare against. Use the live preview to confirm your alarm computes before you rely on it.
Reports reflect live numbers. Because automations read the same datasets as Analytics, anything that changes those numbers — for example a discount lowering the net sale amount — changes what an automation reports too. An automation never invents data; it reflects exactly what your records say at run time.
Related
- AI Assistant (Copilot) — chat, proactive insights, and the four built-in routines
- Analytics & Data Explorer — the datasets, measures, and queries an automation watches
- Modules — enabling the AI Copilot & Automations module