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 to catch anything missed.

Add and edit triggers in the workflow editor under Workflow Settings.

Event triggers

Event triggers run a workflow when something happens in your project.

For the three entity events, choose the entity in Entity. For PushActionTaken, the entity box is the notification category; leave it empty to react to every category.

Note: On EntityCreated, trigger.data holds the fields in the create request, so it doesn't include the new id or values the server filled in. Use {{ $anythink.trigger.id }} for the id, or add a Read data step to load the saved record.

Limit: EntityDeleted appears in the event list but doesn't fire yet. Don't build on it.

Trigger filters

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

Filters are a tree of and, or and not groups around conditions:

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

How filters behave:

• field is a top-level field on the record. Dotted paths and related records aren't supported.
• changed and changed_to only work on EntityUpdated, the only event that knows the previous values.
• Types matter: the boolean true doesn't equal the text "true".
• Text that looks like a date (for example 2026-09-01) is compared as a date.
• An empty and matches everything; an empty or matches nothing.
• An unrecognised op counts as a match, so check spelling — a typo makes the filter let every event through.

The dashboard filter builder covers and conditions. Use the workflow API to save or and not groups.

Timed triggers

Timed triggers run on a cron schedule.

Timed jobs start with an empty payload: there's no trigger.id or trigger.data. Begin with a Read data step to fetch what the job should work on.

Limit: Missed runs aren't caught up. If a timed workflow is disabled, it doesn't run while disabled; when you enable it again it runs once at the next minute, then follows its schedule.

Note: An invalid cron expression is saved but never runs. After saving, check the schedule's next run time.

Manual triggers

Manual triggers add the workflow to the Workflows menu on records of the entities you choose. Running it from a record starts a job with that record's id in {{ $anythink.trigger.id }} and the entity name in the payload; trigger.data is empty, so load the record with Read data if you need its fields.

You can also start a workflow from your own code:

POST /org/{orgId}/workflows/{workflowId}/trigger
Authorization: Bearer <token>
Content-Type: application/json

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

• data is a JSON string, not an object. It becomes trigger.data.
• For a workflow with a manual trigger, entity_name is required and must be one of the trigger's entities.
• The caller needs the anythink_workflows:trigger permission.
• A successful call returns 204 No Content. The job runs in the background.

Limit: anythink workflows create <name> --trigger Manual --entity <entity> saves the trigger with no entities attached, so calls to it are then rejected with "not permitted for this workflow". Until this is fixed, create the workflow first, then set its entities in the Anythink dashboard.

API endpoint triggers

An API endpoint trigger gives the workflow its own route:

POST /org/{orgId}/workflows/api/sync-orders?id=1042&entity_name=orders
Authorization: Bearer <token>
Content-Type: application/json

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

The response doesn't wait for the workflow, so an API endpoint trigger suits fire-and-forget work: imports, syncs and notifications. If your app needs the result, have the workflow write it to a record and read that record.

Workflows with several triggers

• Events: if more than one trigger on a workflow matches the same event, the workflow runs once.
• Schedules: each timed trigger runs independently. Two schedules due in the same minute create two jobs.
• Manual and API calls: when a workflow has both manual and API endpoint triggers, calls may be validated against either one, so an API call can be asked for an entity_name. Keep manual and API triggers on separate workflows.
• Steps can't tell which trigger started the job. If that matters, use separate workflows or check the payload shape in a Condition or Run a script step.

Note: anythink workflows seed doesn't apply a seed file's triggers array — the workflow is created with a single default Manual trigger regardless of what the file specifies, even though workflows export produces a triggers array in the same shape. Add extra triggers in the Anythink dashboard until this is fixed.

Enabling and disabling

• A disabled workflow doesn't run for events or schedules, and its buttons disappear from records.
• Each trigger also has its own Enabled switch.
• Edits apply to jobs that haven't started yet. A job that's already running finishes with the version it started with.

Note: Calls to the trigger endpoint and to API routes check the trigger's Enabled switch, not the workflow's. To stop a workflow's API route, disable that trigger.

Next steps