---
title: How to choose a trigger
url: https://tideswell.xyz/docs/workflows/choose-a-trigger
description: Every workflow starts from a record being created or changed. Watched fields narrow a change trigger to what matters.
---

> Documentation index: fetch https://tideswell.xyz/llms.txt to discover every page before exploring further.

# How to choose a trigger



The **trigger** is what sets a workflow off, and every workflow has exactly one. There are two
kinds: a record being **created**, and a record **changing**. See
<Ref to="workflows/build-your-first-workflow" /> for the whole build.

## How do you pick one? [#how-do-you-pick-one]

Open **Triggers** in the step library. The triggers on offer are grouped by the record type they
belong to, so a workspace with a Repairs Object sees Repairs triggers.

What appears differs per workspace, because it follows the Objects your team has defined. See
<Ref to="objects" />.

## When should you use created, and when changed? [#when-should-you-use-created-and-when-changed]

**Created** for anything that should happen because a thing now exists. A sample request is
logged, so link it to its supplier. A repair is logged, so somebody should look at it.

**Changed** for anything that should happen because a thing moved. A fabric trial reaches
Approved, so tell production. A purchase order's stage moves, so update something.

**Created** fires once per record, ever, which makes it the safer of the two. **Changed** can
fire many times over a record's life, which is why watched fields exist.

## What are watched fields? [#what-are-watched-fields]

On a **changed** trigger you can tick specific details, so the workflow only fires when one of
those changes.

Leave them all unticked and it runs on **any** change to the record, including somebody fixing
a typo in a note.

Tick the ones that matter. A workflow meant to react to a fabric trial being approved should
watch the status field alone; without that it fires every time anybody edits anything on the
record, and it will.

This is the highest-value five seconds in the whole builder. Almost every noisy workflow is a
changed trigger with nothing ticked.

## Is there a scheduled trigger? [#is-there-a-scheduled-trigger]

No. A workflow is a reaction to a record being created or changed rather than something that
runs at a time.

When the thing you want is on a rhythm, use a repeating task instead, per
<Ref to="tasks/make-a-task-repeat" />. When it is a standing watch over your store, use an
automation, per <Ref to="automations" />.

## How quickly does it fire? [#how-quickly-does-it-fire]

Not instantly. Changes are picked up on a cycle of a few minutes, and a change originating in
Shopify takes an extra poll to be noticed.

Wait a few minutes before deciding a workflow is broken, and check the **Runs** tab rather than
the record.

## What can the trigger's record be used for? [#what-can-the-triggers-record-be-used-for]

Everything downstream. Conditions compare it, actions write to it, and its values can be dropped
into a task title or a message.

Every step in a workflow reads and writes **the record that started it**. Reaching a different
record is not something a step does today, and the options panel says so.

That shapes how you design one: a workflow is a reaction to a single record, not a report across
many.

## Why can I not compare or set some fields? [#why-can-i-not-compare-or-set-some-fields]

Because fields that link to another record, such as a task's status, assignee or department,
work differently from plain values.

The builder hides them rather than offering something that would not work, and publishing
refuses them if one somehow gets in. See <Ref to="workflows/add-a-decision" />.

## Can the trigger step be duplicated? [#can-the-trigger-step-be-duplicated]

No, because a workflow has exactly one. Publishing refuses a workflow with no trigger, and one
with more than one.