> ## Documentation Index
> Fetch the complete documentation index at: https://docs.formflows.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Triggers
> Understand every trigger type available in FormFlows.ai and how to configure each one.
A trigger is the starting point of every workflow. It defines the event or condition that causes your workflow to fire. When a trigger fires, FormFlows.ai evaluates any conditions you've set and — if they match — runs all the action steps connected to it.
If a form has multiple workflows with overlapping triggers, each matching workflow runs independently. Triggers are evaluated in the order they were created, but all matching workflows run regardless of the evaluation order. The order does not affect which workflow fires — it only affects the sequence in which triggers are evaluated when you have condition-based triggers that could conflict.
## Available triggers
**What it does:** Fires once for every new submission, regardless of the values the respondent entered.
**When it fires:** Immediately after a respondent clicks the final submit button and the submission is saved to FormFlows.ai. The trigger does not fire for partial saves or abandoned sessions.
**Use cases:**
* Send a confirmation email to every respondent
* Log every submission to a spreadsheet or database
* Notify your team in Slack whenever new data arrives
**Configuration options:**
| Option | Description |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Form** | The form this workflow applies to. Set automatically when you create the workflow from a form's Workflows tab. |
| **Delay before firing** | Optionally wait 0–60 minutes after submission before starting the workflow. Useful when you want to give respondents time to edit their response before processing it. |
No filtering or condition matching is required — every submission triggers the workflow.
**What it does:** Fires only when a new submission meets one or more field-value conditions you define. Submissions that don't match the condition are ignored by this workflow.
**When it fires:** At the moment a submission is saved, FormFlows.ai evaluates the condition against the submitted data. The workflow runs only if the condition evaluates to `true`.
**Use cases:**
* Route high-value leads (e.g., "Budget is over \$50,000") to your sales team
* Send a different confirmation email based on which plan a respondent selected
* Create a Trello card only when a support request is marked "Urgent"
**Configuration options:**
| Option | Description |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Condition field** | The form field whose value you want to evaluate |
| **Operator** | How to compare the value: `equals`, `does not equal`, `contains`, `does not contain`, `is greater than`, `is less than`, `is empty`, `is not empty` |
| **Value** | The value to compare against (not required for `is empty` / `is not empty` operators) |
| **Multiple conditions** | Add up to 10 conditions. Choose **All conditions must match** (AND logic) or **Any condition must match** (OR logic) |
Use OR logic when you want to catch multiple qualifying answers from a single-select field — for example, fire when a respondent selects "Enterprise" **or** "Agency" from a plan dropdown.
**What it does:** Fires when a respondent starts filling out a multi-page or multi-step form but does not submit it within a specified window of time.
**When it fires:** FormFlows.ai checks for incomplete sessions on a rolling basis. When a session has been inactive for longer than your configured abandonment window (default: 1 hour), the trigger fires — but only once per session.
**Requirements:** Abandonment tracking requires your form to be either:
* A **multi-page form** with at least one page completed before the respondent stopped, or
* A **single-page form** with **partial save** enabled in form settings.
**Use cases:**
* Send a "Did you forget something?" reminder email with a link back to the form
* Alert a sales rep when a prospect starts but doesn't complete an inquiry form
* Log abandoned sessions to a CRM for follow-up
**Configuration options:**
| Option | Description |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Abandonment window** | How long to wait after the last activity before treating the session as abandoned. Minimum: 15 minutes. Maximum: 7 days. |
| **Minimum fields completed** | Only consider the session abandoned if the respondent filled in at least this many fields. Prevents the trigger from firing when someone clicks into the form and immediately leaves. |
| **Send at most once per respondent** | If enabled and the respondent later returns and submits, FormFlows.ai will not fire this trigger a second time for the same session. Enabled by default. |
Abandonment data is only available for sessions where FormFlows.ai can track progress — typically embedded forms or forms opened via a direct FormFlows.ai link. Forms submitted through the API do not produce partial session data.
**What it does:** Fires when an existing submission is edited and a specified field's value changes. This trigger is for post-submission edits, not the initial submission.
**When it fires:** When an admin or team member edits a submission from the **Submissions** tab and saves the changes, FormFlows.ai checks whether any watched fields changed. If they did, the workflow fires with the updated submission data.
**Use cases:**
* Notify the original respondent when a team member updates the status of their request
* Re-sync a record to your CRM whenever a submission's owner or stage is reassigned
* Trigger a follow-up email when a support ticket field is set to "Resolved"
**Configuration options:**
| Option | Description |
| -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Watched field** | The field to monitor for changes. You can watch one field per trigger; add multiple workflows to watch multiple fields. |
| **Only fire when new value equals** | Optionally filter to fire only when the field changes to a specific value (e.g., fire only when "Status" changes to "Approved"). Leave blank to fire on any change to the field. |
| **Include old value in workflow data** | When enabled, `{{field.status_old}}` (and similar `_old` suffixed variables) become available in your action steps so you can reference both the previous and new values. |
This trigger only fires when edits are made through the FormFlows.ai interface or via the [Submissions API](/api-reference/submissions). Edits made directly to connected integrations (e.g., updating a Google Sheet row) do not propagate back to FormFlows.ai and will not fire this trigger.
**What it does:** Fires on a recurring schedule, independent of any individual submission event. Use this trigger to build digest reports, scheduled syncs, or timed follow-up sequences.
**When it fires:** At the time(s) you configure using a schedule. The workflow runs on the schedule even if no new submissions have arrived.
**Use cases:**
* Send a daily or weekly summary of all new submissions to your team
* Export the past 24 hours of submissions to a spreadsheet every morning
* Send a follow-up email to respondents who submitted exactly 7 days ago
**Configuration options:**
| Option | Description |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Frequency** | `Hourly`, `Daily`, `Weekly`, `Monthly`, or `Custom (cron)` |
| **Time** | The time of day to run (for daily, weekly, and monthly schedules). Times are in UTC. |
| **Day** | For weekly schedules: the day of the week. For monthly schedules: the date (1–28). |
| **Custom cron expression** | For advanced scheduling, enter a standard 5-field cron expression (e.g., `0 9 * * 1` to run every Monday at 9:00 AM UTC). |
| **Submission window** | When using a scheduled trigger to process submissions, define the time window to query — for example, "submissions from the past 24 hours". This populates `{{submissions.*}}` batch variables. |
**Available variables for scheduled triggers:**
Scheduled triggers provide a different set of variables than submission-based triggers:
```
{{schedule.fired_at}} — ISO 8601 timestamp of when the schedule fired
{{submissions.count}} — Number of submissions in the window
{{submissions.new_count}} — Number of submissions not previously processed
{{submissions.list}} — JSON array of submissions in the window
```
For digest-style emails, combine a scheduled trigger with a **Send email** step. Use `{{submissions.count}}` in the subject line and `{{submissions.list}}` in the body to produce a concise summary without any custom code.