Automations

Advanced  Reviewing every check-in by hand doesn’t scale. An An automation reads a new progress entry and drafts the analysis for you. You stay the editor and the one who sends; the AI just does the first pass.

Automations live under Automations in the side rail. There are two kinds, and they differ only in what sets them off and what they read:

Everything else is identical: the sections, the review step, the sending, what the client sees. The whole loop looks like this:

Set one up

Open Automations and press New automation, choose a kind, then configure. The walkthrough below uses the Progress Report; Reporting on a general form covers what changes for the other one.

1 · Trigger. It fires when a client submits a new progress entry, and you can scope which entries count along four dimensions: Forms, Lifecycle stages, Assigned trainers and Specific clients. Set as many as you like and combine them freely; leave a dimension on Any to ignore it. Only check-ins that match every dimension you have set generate a report, so a “weekly check-in for active clients of Coach Mara” automation stays narrowly on target and never fires on anything else. An ordinary intake or survey submission does not trigger it; only a progress entry does. To report on those, use a Form Report instead.

More than one automation can match. If two active automations both match the same check-in, each one drafts its own report, but the review dialog shows one report per entry. Scope them so they do not overlap.

Only scheduled check-ins auto-run. To avoid noise and wasted analysis, the automation fires only when a client answers a scheduled check-in, meaning a reminder or check-in to-do you set for them. A client’s free-form entry, or one you log for them, does not draft a report.

2 · Data the AI reads. The heart of the analysis is Recent progress entries (0 to 5), which is what gives the AI a trend to reason about. Beside it, Recent coach-chat messages (0 to 20) folds in the conversation, and two switches fold in the client’s onboarding form answers and a client profile snapshot, which is their health, fitness, nutrition and behavioural sections. Each one is genuinely included in what the AI reads when you turn it on.

3 · Sections the AI fills in. A report always has the same three parts, and you can reword how each is written but not add or remove them: a Client-facing summary, Internal notes (trainer-only), and a Priority classifier (STANDARD / URGENT). What each part is for, and how the client eventually sees the summary, is in Progress reports.

4 · After drafting (post-actions). Up to five internal follow-ups: Notify a trainer in the app, Email the coach, WhatsApp the coach, or Set a field on the progress entry (its status, for example). The pipeline never messages the client; that only happens when you press Send on the review.

5 · Save and activate. New automations save as a Draft. Hit Activate to make it live. You can Pause or Archive it later, and it only runs while active.

What it produces

Each run saves a draft report on the check-in: the reply to the client, the internal note and the priority flag. From there it is yours to edit and send, exactly as if you had written it by hand, in the Progress review dialog. The anatomy of a report, how you send it, and what the client sees are all in Progress reports.

An entry holds one report. If an automation runs over an entry that already has one, the new draft replaces it rather than sitting beside it.

Reporting on a general form

Not every question you ask a client is a weekly check-in. A periodic questionnaire, say a habits audit, a mobility screen, or a “how is this phase landing” review sent every six or eight weeks, is a form, and a Form Report automation drafts the same kind of report on it.

Pick the Form Report kind and the setup is the walkthrough above with one difference.

The trigger is the form, and you must pick at least one. It fires when a client submits a form, and unlike every other filter here, Forms is required: you cannot save or activate a Form Report without it. That is deliberate. An empty filter would mean every form a client submits drafts a report, intake questionnaires and one-off surveys included, each one costing an AI run you did not ask for. If you genuinely want reports on all of them, select them all. The other three filters, lifecycle stage, assigned trainer and specific clients, are optional and work exactly as above.

The draft appears on the submission itself: open the submission from the client’s record, or from the form’s submissions list, and the report is there to edit and send, exactly like a check-in report. Sending it delivers it to the client’s app under the form’s name.

A form you fill in for a client does not trigger it. The automation fires on the client’s own submission. If you enter someone’s answers on their behalf, no report is drafted.

Run it and watch the runs

Once active, the automation runs itself on every matching check-in. You can also test it against one entry: the Test run pill at the top jumps to the Run now card, where you paste a progress entry id and press Run now. An archived automation refuses to run and says so.

Each execution shows up in the automation’s run history:

Click a client’s name to open their record at that check-in. Open a run to see exactly what data was sent to the AI and the raw result, which is handy when tuning a prompt. Tokens is the real input and output token count for each run, so you can see what each draft actually cost, and Duration is how long it took.

When a run fails

A failed run means no report was created. There is no report to open and no report id to look up, because the report is the thing that could not be written, so the run detail page shows the progress entry id instead, clearly labelled. That entry is the check-in the run was reading, and the client link takes you straight to it.

The Error column says what went wrong in plain language. The three you are most likely to see:

• “The AI returned nothing” means the request took too long and timed out. This gets more likely the longer you have worked with a client, because every previous entry and their whole onboarding submission go into the request.
• “The AI’s answer was cut off mid-JSON” means the draft was too long to fit in one answer.
• “The report was generated but used N tokens, over this run’s budget” means the draft was written and then discarded for being too expensive.

All three point the same way: the request grew too big. Narrowing what the automation reads, with fewer previous entries or a tighter prompt, is usually the fix. Nothing is lost on the client’s side; the check-in itself is safe.

Nobody is notified when a run fails today. You find out by looking at the run history.

Examples

• Weekly reports for everyone. Pair a Weekly Progress Tracker form, set as your check-in form, with a Progress Report automation scoped to Forms → Weekly progress check-in, every other dimension left on Any. Every weekly submission now drafts a report.
• A different report per segment. Scope one automation to Lifecycle stages → Onboarding and another to Assigned trainers → Mara, each with its own tone, and they will only fire on the clients they belong to.
• Catch the urgent ones. Keep the priority section on and add a Notify a trainer in the app post-action. You get pinged for review, and the urgent flag surfaces the ones that need you first.
• A periodic deep-dive. Send a longer questionnaire every six weeks and pair it with a Form Report scoped to that one form. Each new submission drafts a report on it.
• File the routine ones. Add a Set a field on the progress entry post-action to stamp a status, so new reports arrive already sorted.

Custom automations built for you

Some businesses need a routine that the two kinds above cannot express, for example moving a client from one lifecycle stage to the next once they confirm their plan in chat, or adding a label after a check-in shows they have settled into their program. When Protocol builds one of these specifically for your business, it appears in your Automations list alongside your own, marked Built for you.

A custom automation is read-only in your dashboard. There is no editor, no pause or activate button and no delete: Protocol built it and runs it for you, so to change what it does, or to turn it off, contact support. Open it from the list and you see three things.

• What it does. A plain-language description, written by Protocol when it was built: what sets it off, what it looks at and what it changes. This is the agreed spec for your automation, so if something it does surprises you, this is the first place to look.
• AI steps. Some custom automations ask the AI for a judgement along the way, for example whether a client’s message confirms the plan. Each of those steps is listed by name with its model size (Nano, Light or Heavy), how many times it ran over the last 30 days, the AI credits it used and roughly what that usage is worth, plus a total. One AI credit is one token. These credits come out of your plan’s AI allowance like every other AI feature, and on the billing page they are grouped under Custom automations, see Your Protocol plan.
• Run history. Every run, newest first, with the time, whether it completed or failed, a short summary such as “3 stage changes”, and each change it made: the client (click the name to open their record), what changed, for example “Onboarding to Acclimate”, and where the AI was involved, the reason it gave and the words from the client it relied on. AI step next to a change opens that AI step’s run. A failed run shows its error in place of changes.

The AI steps judge engagement and routine only, the same wellness scope as everything else in Protocol: they never assess a client’s health.

Automated reports vs asking the AI

This automation runs on every check-in, the same way each time: a dependable first draft. For open-ended questions your dashboard never anticipated (“who’s drifting?”, “compare this quarter to last”), use the conversational AI agent instead. The automation is the routine; the agent is the ad-hoc.

That is the engine that drafts your reports. For the report itself, its editing and how it reaches the client, see Progress reports. Back to the Forms & reports overview.