Automations

Run a short sequence of tasks, notifications and signatures whenever something happens — a hire, an approval, a date, or a schedule

An automation is a named sequence that SquadBear runs for one person whenever its trigger fires. "When someone joins, open the onboarding tasks, then ask them to sign the handbook, then tell the team" is one automation. So is "eighty days after a hire date, open a probation review for the manager".

It is the layer above checklists, documents and notifications rather than a replacement for any of them: an automation's task steps become real checklist items, its signature steps become real acknowledgment campaigns, and its notifications land in the ordinary inbox. Everything an automation creates is visible and editable in the module it belongs to — there is no parallel, hidden copy of your work.

Automations live under People → Automations and are admin-only in this version. The page has two tabs: Runs (everything that has fired, newest first) and Templates (the definitions themselves).

What one is made of

Every automation is one trigger plus an ordered list of steps. It always runs about a single person — the subject — and each run measures its due dates from one anchor date.

Nothing fires until you switch the automation on. The designer creates a new automation inactive so you can review the whole sequence before it touches anybody.

Triggers — what starts it

Pick one under What starts it in the designer:

Started by hand — nothing fires on its own. You press Start on the Templates tab and choose a person, or a whole team. Good for a policy acknowledgment you run when the policy actually changes.
When something happens — an internal event: someone joins, someone leaves, an employee record changes, or leave is approved. Event automations run the moment the thing happens, for the one person it happened to.
A number of days from the hire date — fires on hire date + N days, where N can be negative (three days before someone starts). The hire date is the only lifecycle date every employee carries, so it is the only anchor offered. For exits, use the someone leaves event instead.
Every few months of tenure — fires on the person's own anniversary: every 3, 6 or 12 months from their hire date. Anniversaries falling on 29 February land on the 28th in non-leap years.
On a schedule — a cron expression evaluated in your workspace timezone. Minute and hour must be fixed values, so a schedule runs at most once a day. Presets cover daily, weekdays, weekly, monthly, quarterly and yearly.

Filters

Event and schedule triggers can carry filters under Only when — leave is approved and the leave is at least 14 days, or an employee record changes and the field that changed was the manager. Filters join with All (AND) or Any (OR).

No filters means the automation runs for every occurrence of its trigger. If a filter names a field or comparison SquadBear does not recognise, the save is rejected outright. Quietly dropping the rule instead would widen the trigger to match everyone — the opposite of what you asked for, and invisible until it had already fired.

Cooldown (schedules only)

A schedule re-scans your whole workspace on every tick, so without a cooldown the same matching people re-enter the fan-out every single day. The cooldown skips anyone who already matched within the last N days. The designer warns you when a frequent schedule has no cooldown, and warns harder when that schedule notifies an admin, a manager or a whole team — those multiply.

Steps — what it does

Steps run in order. There are three kinds:

Task — a real checklist item for the run's subject, their manager, an admin, or one specific named person. It can require a document upload, and require that upload to be verified by an admin or manager. Its due date is an offset in days from the anchor date (negative means before it).
Notification — an in-app message to the subject, their manager, an admin, a specific person, or the subject's whole team. You write the title and the body.
Signature — asks for an acknowledgment of a workspace policy document, either from the subject only or from every active employee. Personal files cannot be used.

Every task step of a run shares one checklist for that person, so their onboarding is a single list rather than a scatter of one-item checklists. Steps are appended to it as they open.

Personalising a message

Task titles, notes and notification bodies accept @tokens, resolved when the step opens:

@affectedperson · @affectedpersonfirst · @manager · @team · @role · @location · @startdate · @enddate · @leavetype · @durationdays · @workflow · @duedate

Type @ in the designer to pick one. A token with no value for that run (a person with no manager, a run with no leave attached) resolves to an empty string rather than printing the raw token, and the designer flags tokens it does not recognise before you save.

Gates — making later steps wait

A task or a signature step can be marked a gate: every later step stays Waiting until that step is completed. That is how "collect the signed contract, then ask for the handbook signature, then announce the new joiner" works, and the wait holds across engines — a checklist item can gate a signature campaign, and a signature can gate an announcement.

Three consequences worth knowing:

A gate that has already been decided cannot be reopened once the steps behind it have opened. Reopening it would leave work that only exists because the gate passed. Revoking a signature behind an opened gate is recorded in the audit log but does not put the run back to work either. The correction in both cases is to cancel the run and start a new one.
A gate that fails leaves everything behind it waiting. The run inspector says so explicitly at the top of the timeline, naming the step that is holding things up.
A notification never gates, and it is not a policy we chose: an in-app notification is delivered the instant the step opens, so there is no interval during which anything could wait for it. If you want "tell them, then wait", the thing you want is a task.

Escalation

A task or signature step can escalate when overdue: N days after its due date, SquadBear sends one in-app reminder to an admin, the subject's manager, or a named person.

Escalation is deliberately a nudge and nothing more. It never reassigns the work, never completes it, and never fires twice for the same step. If the escalation target is not reachable any more — a manager who has left, a pinned person who was deactivated — the step is marked as escalated without a message rather than retrying forever.

Runs — what actually happened

Every fire creates a run: one automation, one person, one anchor date. Open it from the Runs tab to see the step timeline with each step's state — Waiting, Open, Done, Failed or Skipped — its due date, whether it escalated, and links straight into the checklist or the signature campaign it created.

Runs are idempotent by person. A hire fires an event automation once for that person, ever. A leave approval fires once per request. A daily scan fires at most once per person per day. A retry, a duplicate event, or a repaired background job converges on the run that already exists instead of creating a second one.

Cancelling a run skips every step that has not started yet. Work already assigned — an open checklist item, an open signature campaign — is deliberately left in place, because somebody may already be halfway through it. Cancel it in the module it lives in if you also want it gone.

If a step cannot run at all — the checklist module is switched off, or a signature step points at a document that has been deleted — that one step fails with a readable reason and the failure is visible on the run. The rest of the run is unaffected, and nothing about the hire, the approval or the offboarding it rode on is blocked.

Starting one by hand

On the Templates tab, Start on an active manual automation asks for:

One person — the run is created immediately and you land on its inspector.
A whole team — every active member gets their own run. The fan-out is queued in pages, so runs appear over the following minutes rather than all at once. That is what keeps a 200-person team from timing out.

You can also override the anchor date, so an onboarding pack started late still measures its due dates from the real hire date.

Packs to start from

The Templates tab offers ready-made packs — New joiner onboarding, New employee announcement, Offboarding and equipment return, Long-term absence coverage, Manager change handover, Probation review, Work anniversary alert, Policy acknowledgment campaign and Annual security awareness.

A pack opens the designer pre-filled; it is a first draft, not a commitment. Nothing is saved until you press create, and packs with a signature step need you to pick one of your own workspace documents first — a pack cannot ship a document you have not uploaded.

The YAML view

Each automation is one document, and the designer's YAML tab shows it. It is the same interchange format agents use over MCP and the API (as JSON), so you can copy an automation between workspaces, review one in a pull request, or hand one to an agent to edit. Paste YAML back in, press Apply to the form, and it is validated before it touches anything.

Limits

Free plan: 3 active automations. Drafts are unlimited — the cap is on how many are switched on at once. Paid plans are uncapped.
100 active automations per workspace, on every plan. This is a safety bound on fan-out, not a packaging lever; if you hit it, deactivate something.
50 steps per automation, and 20 filter rules per trigger.
An automation that already has runs cannot be deleted — deactivate it instead, so its history stays readable.

Not in this version

Being straight about the edges, so you do not design around something that is not there:

Notifications are in-app only. No automation email, no automation Slack messages. Automation bodies are written by you while SquadBear's email templates are static and translated; reconciling the two is a real design problem and shipping half of it would mean sending untranslated mail nobody could unsubscribe from cleanly.
Steps run in a straight line. No branches, no parallel arms, no loops.
Schedules are daily at their most frequent. No hourly or minute-level triggers.
Automations are admin-only. Managers and employees see the work an automation creates — their checklist items, their notifications, their signature requests — but not the automations page itself.

Worked example

Northlake hires Priya, starting 1 September. Their New joiner onboarding automation is active and triggered by someone joins, so the moment Marta creates Priya's record a run appears.

Step 1 is a task for an admin, "Prepare kit and accounts for @affectedperson", due three days before the start date. Step 2 is a task for Priya with a document upload — the countersigned contract — and it is a gate. Steps 3 and 4 (the handbook signature and the team announcement) sit at Waiting.

Priya uploads her contract on day one, an admin verifies it, and the gate clears. The handbook campaign opens for her with a seven-day due date, and the team notification goes out. Nobody chased anything. Nine days later the signature is still unsigned, so the escalation Marta configured sends one reminder to Priya's manager — and only one.