# 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.

- Source: https://spiich.ai/help/workflows/workflow-triggers-and-schedules
- Section: Workflows
- Who can do this: Everyone
- Time: 7 minutes
- Last updated: 2026-08-24

## 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](/help/background-agents/background-agents-overview) and [Triggers and schedules for agents](/help/background-agents/agent-triggers).

## 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.

> **Admin only:** Deciding whether a workflow is offered in Tables, and on which tables, is admin-only. Open the workflow's details panel, find **Run from Tables**, and turn on **Offer in Tables**. Leave the table list untouched to offer it on every table holding that record type, or tick specific tables to narrow it down. Click **Save**; it applies immediately and does not need a new version. A non-admin sees the current setting stated read-only, with a note that an admin can change it. It only appears in Tables while the workflow is **Live**.

Once it is offered, here is what a rep sees:

1. **Select rows**
   Open the table and select the records the workflow should act on.

2. **Open Run workflow**
   In the bulk action bar, click **Run workflow** and choose from the list.

3. **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.

4. **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.

## Frequently asked questions

### Can I make a workflow react to a CRM change the instant it happens?

Not from the trigger editor; Event is shown as "coming soon" and cannot be selected. Use a background agent with an event trigger instead, or a scheduled workflow with a tight record filter if a short delay is fine.

### What is the difference between the record filter and Run from Tables?

The record filter decides which records a scheduled or manual run picks up on its own. Running from Tables ignores that filter entirely and acts only on the rows a person selected.

### Who can turn on Run from Tables for a workflow?

Only workspace admins. Everyone else sees the current setting as read-only text.

### What happens if I leave Max records per run at 0?

The run has no cap on how many records it processes. It works through everything the filter matches, subject to Page size and any Successful target you set.

## Related

- [What workflows are](https://spiich.ai/help/workflows/workflows-overview)
- [Build a workflow](https://spiich.ai/help/workflows/build-a-workflow)
- [Test and monitor workflow runs](https://spiich.ai/help/workflows/test-and-monitor-workflow-runs)
- [Tables and views](https://spiich.ai/help/your-data/tables-and-views)
- [Background Agents](https://spiich.ai/product/background-agents)