Two related things live here. Automation reacts to events and does something. Workflow tracks work items moving through stages, with assignment, targets and escalation.
Automation
An automation has three parts:
| Part | What it is |
|---|---|
| Trigger | What starts it — a record changing, a schedule, an inbound message, a webhook |
| Condition | What must hold for it to continue |
| Action | What it does — send, create, update, call out, escalate |
Automations run in the background, so a slow one never blocks whatever started it. You can run one immediately to test it rather than waiting for its trigger to fire.
Phone menus are built the same way, with the incoming call as the trigger.
Describing instead of building
An automation can be generated from a plain-language description, then improved or validated before you enable it. You review what it produced rather than trusting it blindly.
Workflow
A workflow tracks work through stages — a kitchen order, an approval, a repair, a reservation. Any record can carry one.
Tasks move by advancing to the next stage or jumping to a named one, and can be reassigned, annotated, cancelled, completed and archived. Every move is recorded, so a task carries its own history.
SLAs and escalation
This is what separates a workflow from a status field.
Tasks can carry a target time. Two views matter, and they are deliberately different:
- Upcoming — approaching breach. This is the list you act on.
- Breached — already past target. This is the list you explain.
A task can be snoozed, or escalated immediately. Escalation runs on its own rather than depending on someone watching a queue.
Analytics
Wait times per workflow show where work actually stalls, and a task's estimated completion is predicted from that history — which is what a customer-facing "ready in about 12 minutes" display uses.
Schedules
A schedule does one thing to one or more records at a set time, once or on repeat: send, publish, unpublish, delete, run, start, stop, or update a status or state. Most schedules belong to a record — a message or broadcast set to go out later, a post set to publish — and are made from that record: the compose screens and a record's properties panel carry a schedule editor, and what you set there is tied to the record.
AI, IVR & Automation › Schedule is where every schedule in the organization can be seen and managed. Its tabs:
| Tab | What it shows |
|---|---|
| Overview | Totals — active, paused, completed, failed — and what is actually queued to run |
| Upcoming | What runs next |
| List | Every schedule, filterable by status, with start, pause, view, settings and delete on each |
| Calendar | Schedules laid out by date |
| Runs | Past executions, with their status, duration and logs |
| Logs | Schedules where the saved record and the run queue disagree |
New Schedule sets Run at for a single run, or Repeat — every so many minutes, daily, weekly, monthly, yearly or a custom cron expression — with When it ends, the action and the records it acts on.
A schedule runs from a queue, not from the saved record alone, so the two can drift apart. Logs lists both kinds of drift: a saved schedule with nothing queued (Sync to Redis queues it again) and a queued entry with no saved schedule behind it, which is left for a platform administrator to inspect before it is removed.