EnglishENPolskiPLDeutschDEEspañolESBahasa IndonesiaID
Start free
Documentation

Processes

View as Markdown
Ask AI

Define multi-step work once - onboarding, offboarding, a manager change, an annual training - with triggers, assignee roles and step dependencies

A process is multi-step work SquadBear runs for one person - a joiner's first week, an annual training. Each firing creates a run, with one action per unit of work.

Processes is its own sidebar entry; the catalog is admin-only. Everyone else works their steps in Inbox, where each row names the process and subject.

Triggers

event fires on a hire, an offboard, a manager change or an approved leave request. date counts days from the person's start date, recurring repeats on its anniversary, manual waits for Start.

Rules narrow employee.updated and request.approved - "leave longer than 10 days". Durations are minutes at 480 a working day, so 10 days is 4800. A rule on a hire or an offboard is rejected at validation; both run for everybody.

Actions

  • Task: a step someone ticks off.
  • Upload: completed by a document. Requires verification holds it for an admin or the subject's manager, who never reviews a run about themselves.
  • Decision: two to six outcomes. An Only run if… condition on a later step names one; losing branches are skipped, and everything behind them.
  • Message: an in-app notification to the subject, their manager, an admin or a team, sent verbatim - no field substitution.
  • Policy acknowledgment: the subject signs a policy; everything downstream waits.

A Waits for list holds an action closed until every step on it is done. Stages group steps and compile into those dependencies.

Assignees

An action names a role: subject, manager (theirs when the run starts), admin (the first active admin other than the subject) or person (a pinned employee). An unresolved role falls back to that admin, then the subject if active; the run records which. With neither, the start is refused with a 409.

Runs

The Runs tab lists every run with person, process, version, progress and state. A run finishes when every action reaches a terminal state, and fails only when a required automatic step could not be done, freezing the work behind it. An admin or the subject's manager can cancel a run; finished work stays. One active run per process per person. Saving publishes a new version; runs in flight keep theirs.

Activating

New joiner onboarding and Employee offboarding ship active in new workspaces. New process on Processes lists all seven templates.

Activating counts against the plan's allowance; drafts do not. Free includes three and the two seeded processes hold two, so the third returns 402 upgrade_required. Every plan stops at 100 active.

Activation arms date and recurring occurrences one per person in UTC days, future ones only. Also catch people up adds one dated today for everyone past. Arming is one pass over the roster, so a dated or recurring process above 2,000 active people is refused with a 409.

Start runs one now for a person or a team: one queued run per active member; anyone already running is skipped.

Worked example

Aleksandra joins Northlake on 1 March. Her record starts the seeded New joiner onboarding run: "Prepare laptop and accounts" for her manager due 1 March; "Complete the HR paperwork" and "Upload the signed contract" for her due 3 March. The "Welcome to the team" message waits on all three, because Day one waits for Prepare.

For agents

get_process_schema returns the document format and trigger catalog. upsert_process, set_process_active, start_process, list_process_runs, reject_process_upload and reopen_process_action do the rest.