What a workflow is
A workflow is a trigger and one or more actions. When the trigger fires, the actions run, and you can read afterwards exactly what happened.
Workflows is a page of its own in the left navigation. Only owners and admins see it, because a workflow acts on the whole workspace.
Triggers
| When | Notes |
|---|---|
| An invoice is sent | |
| An invoice is paid | in full |
| An invoice goes overdue | you choose how many days; checked nightly in your workspace timezone |
| An estimate is approved | |
| A job is created | |
| A job changes status | optionally only when it lands in one status you pick |
| A job is completed | any won status counts |
| A visit is booked | a measure, an install, an assessment, or a service agreement visit, once it has a date; see below |
| A visit is completed | marked done from the office, the crew’s visit link, or the API |
| Days after one of the above | for the follow-up that should wait |
Visits are not jobs
Booking a visit does not run Job created, and a visit’s progress does not run Job status changed or Job completed. Those triggers are about the job on your board. For anything per visit, such as “text the customer when their install is booked” or “ask for a review two days after a visit is done”, use the two visit triggers.
- Each runs once per visit. Moving a booked visit to another day does not run Visit booked again, and a visit reopened and marked done a second time does not run Visit completed again.
- When a service agreement books several visits at once (when you create it, or choose Generate now), Visit booked runs once, for the first of them, so the customer gets one message instead of eight. After that, each new visit the agreement adds runs it on its own.
- Your customer message settings already cover two of these moments: Booking confirmations texts the customer when a visit is scheduled, and Post-visit follow-up thanks them the day after. A workflow that sends the same news while those are on sends it twice.
Actions
- Change job status: move the job to a stage on its board.
- Notify your team: an in-app notification to every owner and admin.
- Send an email to the job’s customer.
- Send a text to the job’s customer. Texts respect opt-in: a workflow never texts someone who has not agreed to texts, and every text carries the STOP footer.
- Call a webhook, for the technically inclined: Crewfather posts the event to a URL you give it, signed so the receiving system can verify it came from you.
Messages that fill themselves in
Email and text actions take templates with variable chips: the customer’s name, the invoice number, the amount due, a payment link, an approval link, and for the visit triggers the visit’s date, arrival window, address and crew. The editor lists exactly which variables the chosen trigger provides and warns you about one it does not.
The editor
Open a workflow and you get a full-screen editor: the chain as connected blocks on a canvas, with Builder, Settings and Execution Logs tabs.
Two things worth knowing:
- Nothing saves until you choose Save. You can rearrange freely and back out.
- Test runs it dry. The Test button renders every message and names every step’s outcome without sending anything or touching any job. Use it before you publish, not after.
A workflow does nothing until it is published, and you can unpublish one from the list without deleting it.
The four ready-made workflows
Every workspace comes with four: estimate sent moves the job to Estimate, estimate approved to Scheduled, invoice sent to Invoiced, and a paid invoice lands the job in Closed and notifies the owners.
A new workspace starts with them running. An older workspace has them as drafts, waiting for you to review and publish, so nothing started moving your jobs without you agreeing to it.
Runs you can read
Execution Logs keeps the recent history of each workflow. A step that could not run says why, in words: no email address on file, or the customer has not opted in to texts. When a workflow seems to have done nothing, this is where the answer is.