Triggers and schedules
A workflow has exactly one trigger: run it by hand, put it on a schedule with a plain-English preview, or filter it to matching CRM records, with page size, record caps and a rerun policy controlling every run.
Before you start
- A saved workflow with at least one step.
- A connected CRM, if you want the trigger to run over matching records.
Every workflow has exactly one trigger, set in two parts: when it runs, and what goes into each run. Click the trigger node at the top of the canvas to open it.
When to run
Three options sit under When to run, though only two are ever something you pick yourself.
Manual starts runs only when someone presses the button. Nothing fires on its own.
Schedule runs the workflow automatically on a cron schedule. Pick a preset under Runs: Every day at 08:00, Every weekday at 08:00, Every hour, Every Monday at 09:00, Monthly on the 1st at 08:00, or choose Custom cron expression and type your own, for example 0 8 * * *. Whichever you pick, a plain-English line under the field restates the schedule back to you, so you can check it matches what you meant before you save. Set a Timezone underneath; the schedule is evaluated in that timezone.
Event appears in the trigger editor but is disabled, labeled "Event (coming soon)," with the note "Event triggers are not dispatched yet." A workflow starts manually, on a schedule, or from a table, full stop. If what you actually want is for something to happen the moment a CRM record changes, that is what background agents are for. See What background agents are and Triggers and schedules for agents.
What to include in the run
Below the trigger type, choose what data goes into each run.
One run starts a single run with only the trigger payload, no record loop. Matching CRM records fetches records from your CRM and runs the workflow once per record, which is what you want for anything that has to touch every matching Deal, Contact, or Organization.
Choosing Matching CRM records opens the record type picker and a Record filter: build conditions from a Field, an Operator (contains, equals, is empty, is not empty, or Yes/No for boolean fields), and a Value. Only records matching every condition enter the workflow. Leave it empty and the trigger reads every record of that type.
Limits and reruns
Underneath the filter, Limits and reruns controls how big and how repeatable a run is.
| Setting | What it does |
|---|---|
| Page size | How many matching records to fetch per page. |
| Max records per run | Stop after this many records enter the workflow. Use 0 for no cap. |
| Successful target | Stop after this many records finish successfully. Use 0 for no cap. |
| Rerun policy | Run once per record ever, rerun when the workflow changes, rerun after a set number of days, or always rerun. |
The name under Call each record is what later steps use to read the current record, for example currentContact.
The rerun policy is what stops a scheduled workflow reprocessing the same records every time it fires. "Run once per record, ever" means a record that already went through successfully is never picked up again by this workflow. If you change the workflow's steps, "Rerun when the workflow changes" lets it revisit records under the new logic.
Running a workflow from Tables
A workflow whose trigger reads CRM records can also be started by hand from inside a table, but who gets to turn that on is not up to every member.
Once it is offered, here is what a rep sees:
Select rows
Open the table and select the records the workflow should act on.
Open Run workflow
In the bulk action bar, click Run workflow and choose from the list.
Read the confirmation
The dialog states plainly: it runs on the records you picked and nothing else. The workflow's own record filter is ignored entirely, so it acts on these rows even if its filter would not otherwise have chosen them. Credits are used as each step works, and the run is billed to you.
Confirm
Click Run workflow. A toast confirms it started, and you can follow it from the workflow's Recent runs list.
Limits
- A workflow has exactly one trigger.
- Matching CRM records cannot be combined with an event trigger.
- Spiich checks a custom cron expression is valid before you can save it.
- A run started from a table accepts at most 50 selected records.
- A workflow can be limited to at most 50 specific tables under Run from Tables.
- A table only offers a workflow when its trigger reads the same kind of record the table holds, it has been offered for Tables, and it is currently Live.
If something goes wrong
The custom cron field says "This is not a valid cron expression yet." The expression is malformed. Use the format minute hour day month weekday, for example 0 8 * * * for 08:00 daily, and check the plain-English preview updates once it is valid.
The workflow runs at a time you did not expect. Check the Timezone field under the schedule; the schedule is evaluated in that timezone, not automatically your own.
The workflow does not show up in a table's Run workflow menu. One of: Offer in Tables is off, the workflow is limited to other tables, the workflow is not Live, or its trigger reads a different record type than the table holds. An admin needs to check Run from Tables in the details panel and confirm the workflow is activated.
Run from Tables shows text instead of controls, telling you to ask an admin. Choosing where a workflow can run is admin-only. Ask a workspace admin to change it; the message tells you whether it is currently offered or not.