Triggers and scheduling

A trigger decides when a workflow runs and what data the job starts with. A workflow can have several triggers of different types. For example, run when an order is created and every night at 02:00. Any of them starts the same steps.

Every job starts with a payload of id, entity_name and data. Steps read them as {{ $anythink.trigger.id }}, {{ $anythink.trigger.entity_name }} and {{ $anythink.trigger.data.<field> }}. Each trigger type fills them differently, as the sections below show. For the model behind jobs and steps, see How workflows work.

Add a trigger

Every workflow needs at least one trigger. You choose the first when you create the workflow, and you can add more later.

# Event: a record changes
anythink workflows create order-paid \
  --trigger Event --event EntityUpdated --entity orders --enabled

# Timed: a cron schedule, in UTC
anythink workflows create nightly-report \
  --trigger Timed --cron "0 2 * * *" --enabled

# API route: no leading slash
anythink workflows create sync-orders \
  --trigger Api --api-route sync-orders --enabled

Event triggers

An event trigger runs a workflow when something happens in your project. Pick an Event Type. The dashboard shows the names below with spaces (Entity Created), and the CLI and API use them as written.

For EntityCreated and EntityUpdated, choose the Entity to watch. The trigger can't be saved without one, and the entity has to exist. {{ $anythink.trigger.entity_name }} holds its name.

Payment and subscription events are raised for Stripe activity. See Webhooks for the data each carries and an end-to-end example. For PushActionTaken, iOS button group is the notification category, and leaving it empty matches every category. See Push notifications from a workflow.

Event triggers fire for changes made by any route into the data: the REST API, the Anythink dashboard, imports, and other workflows' Create data and Update data steps. A workflow that updates the entity it watches starts itself again, so give it a filter that stops the loop.

Trigger filters

A filter makes an event trigger skip events you don't care about. It's checked before a job is created, so a filtered-out event creates no job and leaves nothing in Job History.

A filter is a tree of and, or and not groups around conditions:

{
  "and": [
    { "field": "status", "op": "changed_to", "value": "paid" },
    { "field": "total", "op": "gte", "value": 100 }
  ]
}

Use only the operators in this table.

• field is a top-level field on the record. Dotted paths and related records aren't supported.
• On EntityCreated, the filter sees only the fields in the create request. On EntityUpdated, it sees the whole record after the update.
• changed and changed_to need the previous values, which only EntityUpdated has. They never match on other events.
• Types matter: the boolean true doesn't equal the text "true". Text that looks like a date, such as 2026-09-01, is compared as a date.
• An empty and matches everything and an empty or matches nothing.
• For PushActionTaken, the filter runs against the trigger data, so { "field": "action_id", "op": "eq", "value": "snooze" } reacts to one button.

anythink workflows create order-paid \
  --trigger Event --event EntityUpdated --entity orders \
  --filter '{"and":[{"field":"status","op":"changed_to","value":"paid"},{"field":"total","op":"gte","value":100}]}' \
  --enabled

Timed triggers

A timed trigger runs on a cron schedule.

A scheduled job has no record behind it. $anythink.trigger.id and $anythink.trigger.data are empty and entity_name is null. Begin with a Read data step to fetch what the job should work on. Each due schedule starts one job, and a schedule that was missed isn't replayed.

anythink workflows create nightly-report \
  --trigger Timed --cron "0 2 * * *" --enabled

anythink workflows trigger 42
anythink workflows jobs 42

Manual triggers

A manual trigger lists the entities it applies to. On the detail page of a record in one of those entities, the Workflows section lists the workflow with a play button. Selecting it and confirming starts a job with that record's id in {{ $anythink.trigger.id }} and the entity name in {{ $anythink.trigger.entity_name }}. trigger.data is empty, so load the record with a Read data step if you need its fields.

Your code can start the same job:

POST https://api.my.anythink.cloud/org/{project_id}/workflows/{workflow_id}/trigger
x-api-key: <your key>
Content-Type: application/json

{
  "entity_name": "orders",
  "entity_id": 1042,
  "data": "{\"reason\":\"manual resend\"}"
}

The caller needs the anythink_workflows:trigger permission. A successful call returns 204 No Content and the job runs in the background. See API keys for creating a key that carries only that permission.

anythink workflows trigger 42 \
  --entity orders --entity-id 1042 \
  --payload '{"reason":"manual resend"}'

API route triggers

An API route trigger gives the workflow its own route:

POST https://api.my.anythink.cloud/org/{project_id}/workflows/api/sync-orders?id=1042&entity_name=orders
x-api-key: <your key>
Content-Type: application/json

{ "source": "shopify", "since": "2026-09-01T00:00:00Z" }

The response doesn't wait for the workflow. This suits fire-and-forget work such as imports, syncs and notifications. If your app needs a result, have the workflow write it to a record and read that record. Webhooks covers creating the key and an end-to-end example.

anythink workflows create sync-orders \
  --trigger Api --api-route sync-orders --enabled

anythink fetch "/workflows/api/sync-orders?id=1042&entity_name=orders" \
  --method POST --body '{"source":"shopify"}'

Workflows with several triggers

• Events: if more than one trigger on a workflow matches the same event, the workflow runs once. If several workflows watch the same event, each starts its own job.
• Schedules: each timed trigger runs on its own schedule.
• Which trigger started it: steps can't tell. If it matters, use separate workflows, or branch on the payload's shape with a Condition or Run a script step.

Enabling and disabling

• The workflow's Enable Workflow setting stops its event and timed triggers from starting jobs, and hides its buttons on records.
• Each trigger also has its own Enabled switch. Clear it to stop one trigger and leave the rest running.
• For an API route, the trigger's Enabled switch decides whether the route answers. Clear it and callers get 404.
• Changes apply to jobs that haven't started yet. A job that's already running finishes with the version it started with.

Check it worked

Fire the trigger once, then read the job.

1. Cause the event, wait for the schedule, press the record button, or call the route.
2. Open the workflow, select View Job History in the toolbar, and open the newest job. It shows the payload the trigger produced and the log and output of every step.
3. Or run anythink workflows jobs <workflow_id>.

If an event trigger with a filter produced no job, the filter didn't match. Check the field name and value against the data in the table above, remembering that EntityCreated only has the fields that were sent. Test workflows and read job history covers reading jobs and tracking down failures.

Next steps