Automations Overview

Automations let you chain ClientCove actions into a workflow that runs by itself — on a schedule, on demand, or triggered by your AI assistant. Think "every Monday at 9am, create a check-in task for each active client" or "when a ticket comes in, acknowledge the client and assign the next rep."

The Automations list — every workflow with its trigger, status, and last run. The header bar holds Import, Start from a recipe, and New automation, plus a show technical names toggle for advanced editing.

What Automations Are

An automation is a named, saved workflow made of three parts:

1. A trigger — what starts it (a schedule, a manual click, or your AI assistant).
2. Conditions (optional) — guards that decide whether the automation, or an individual step, should run.
3. Actions — an ordered list of steps. Each step runs one tool: create a task, reply to a ticket, update a client, send a test email, and so on.

The actions come from the same tool catalog that powers the MCP integration — so anything your AI assistant can do, an automation can do unattended.

Where to Find It

Open /automations/ on your portal (the page is created automatically the first time an administrator visits it). You'll land on the Automations list — every workflow you've built, with its trigger, status, and last run time. From the header you can create a New automation from scratch, Start from a recipe, or Import one that was exported elsewhere.

There's no feature flag to flip — the automations engine is active on every portal running v2.59.10 or later.

Starting from a Recipe

The fastest way to your first automation is a recipe — a ready-made template you fill in and save as a draft. Click Start from a recipe in the header to browse them, grouped by area (Tickets, Billing, and more).

Each recipe describes what it does and lists the details you'll supply — for example "Days with no update" or "Hours threshold" — before you save it as your own draft.

Recipes are a starting point, not a black box: once saved, a recipe opens in the same editor as any other automation, so you can rename it, adjust the trigger, and add or remove steps.

How an Automation Is Built

Every automation is built in a single visual editor. Name it at the top, then work down the panel — trigger, conditions, and steps — while the Dry-run preview on the right shows what a run would do before you commit.

The flow is always the same:

1. Name it — give the automation a clear title (e.g. "Weekly client check-in").
2. Describe it in plain English (optional) — a one-line summary such as "When a ticket sits 2 days with no update, ping the manager." It documents the automation and helps your AI assistant reason about it.
3. Pick a trigger — Manually, on a schedule, on a schedule for matching records, or when something happens (see Trigger Types).
4. Add conditions under Only run if (optional) — only run when the incoming data matches, e.g. Client is Acme or Amount is over 100.
5. Add action steps — a tool step, a wait, a stop, or a variable (see Action Step Types). Drag to reorder.
6. Dry-run to preview, then Save and enable it.

See Building an Automation for the full walkthrough, and Triggers, Conditions & Actions for the complete reference of what's available.

Action Step Types

An automation's body is an ordered list of steps. The Action Steps toolbar offers four kinds:

Button	Step	What it does
Add step	Tool step	Runs one tool — send a notification, create a task, reply to a ticket, generate a report. Each input can be a fixed value, pulled from the trigger context, or built from a template.
Add wait	Wait	Pauses the run — "wait 3 days, then continue" — for a relative delay or until a specific date. The automation resumes on its own and survives server restarts.
Add stop	Stop	Ends the run early when its conditions are met. Combined with per-step conditions, this gives you if/else "then / else" paths in a plain linear list.
Add variable	Set variable	Names a value (from an earlier step or the trigger) so later steps can reuse it as {vars.name}.

Any step can carry its own Conditions — guards that decide whether just that step runs. Below, a three-step drip: send a welcome notification, wait 3 days, then send a check-in.

Trigger Types

The trigger decides what starts a run. Pick it from the Trigger dropdown at the top of the editor.

Type	UI label	What starts the run
Manual	"Manually (on demand)"	You click Run in the list, or your AI assistant calls run_automation.
Scheduled	"On a schedule"	A recurring time — hourly, daily, weekly, or monthly.
Scheduled, per record	"On a schedule, for matching records"	On a schedule, runs your steps once for every record that matches your conditions. See Act on Matching Records on a Schedule.
Event	"When something happens"	A portal event such as a new client, a newly opened ticket, an intake submission, or a marketplace purchase.

The Automations List

The list view is your control panel. Each row shows:

Column	Meaning
Name	The automation's title, with a one-line description beneath it
Trigger	Manual / On a schedule / On a schedule, for matching records / When something happens
Status	A toggle to enable (publish) or disable (draft) the automation
Last run	A relative timestamp (e.g. "4h ago", "1d ago") — or "—" if it hasn't run yet

The Actions column gives you per-row controls: Edit the configuration, Dry-run it to preview every step without making changes, Run it immediately, export it, and delete it. Expand a row (the ▸ chevron) to see its steps and recent run history inline.

Toggle show technical names in the header to reveal each field's underlying key — handy when mapping values or debugging a step.

Safety & the Destructive Gate

Steps that change data — create, update, reply, complete, delete — are marked destructive. When an automation runs unattended (on a schedule), those steps only fire if you've ticked "Allow destructive steps to run unattended" on the automation.

This is a deliberate safety brake: a brand-new scheduled automation won't silently start creating records until you've explicitly opted in. Read-only steps (get, list) always run.

Every run — live or dry — is recorded with its trigger, the user it ran as, and the outcome of each step, so you can always see what an automation did and when.