How workflows work

Workflows are Anythink's automation engine. Use them for the logic that would otherwise need a backend service: reacting to new records, running nightly jobs, exposing an endpoint that does several things at once, calling other APIs, and sending email or push notifications. Nothing to host, and no server code.

This page explains the model and what happens at runtime. To build one, start with Build your first workflow.

The moving parts

Steps are connected, not just ordered. Each step has an on success link and an optional on failure link to another step. One step is the start step. A job begins there and follows links until a step has nowhere left to go. In the editor, the green handle on a step is on success and the red handle is on failure.

What happens when a workflow runs

1. A trigger fires. A record is created or updated, a schedule comes due, someone runs the workflow by hand, or your code calls its API route.
2. Anythink creates a job with the status Pending and a payload of { id, entity_name, data }, then queues it for the workflow worker. For an event trigger with a filter, the filter is checked first. If it doesn't match, no job is created.
3. The worker picks the job up. It checks your plan's workflow quota and sets the job to Running.
4. It runs the start step. Templates in the step's parameters, such as {{ $anythink.trigger.data.email }}, are resolved just before it runs.
5. The step's output is saved. Later steps can read it as $anythink.steps.<key>.data.
6. The worker follows a link. A successful step follows on success. A failed step follows on failure.
7. The job finishes. See Success and failure paths.

Jobs run on a separate worker, not in your request. A record you create returns straight away, and the job follows moments later.

Triggers

A trigger that watches an entity must name an entity that exists. The workflow has an Enable Workflow setting, and each trigger has its own Enabled setting, so you can switch one trigger off without touching the others.

Event triggers

Pick an Event Type. The dashboard shows the names below with spaces, and the CLI and API use them as written.

On a record event, the trigger data doesn't include the id, so read the record's id from $anythink.trigger.id. Payment and subscription events are raised for Stripe activity. See Webhooks for the details.

An event trigger can carry a filter so the workflow only runs when it matters, for example only when an order's status changes to paid. A filter compares a field with a value using =, ≠, >, ≥, <, ≤, in, contains, is null or is not null. On an update it can also test whether a field changed or changed to a value. Conditions combine with All of these or Any of these. Details are in Triggers and scheduling.

Timed triggers

A timed trigger uses a standard five-field cron expression, such as 0 6 * * * for 06:00 every day. Schedules are in UTC, and Anythink checks for due schedules once a minute, so the finest resolution is one minute. A scheduled job has no record behind it: $anythink.trigger.id and $anythink.trigger.data are empty. Each due schedule starts one job, and missed runs aren't caught up.

Manual triggers

A manual trigger lists the entities it applies to. Those entities' records get a button in the Anythink dashboard that runs the workflow on that record. Your code can do the same by calling the workflow's trigger endpoint, which needs the anythink_workflows:trigger permission and takes the entity name, record id and data you send.

API call triggers

An API call trigger gives the workflow its own route. Callers POST JSON to it with an API key, the body becomes $anythink.trigger.data, and the response is 204 No Content as soon as the job is queued. The request doesn't wait for the result. Webhooks has the URL, the rules for routes, the permission the caller needs and an end-to-end example. To create a key for the caller, see API keys.

Steps

Each step has a name, a key and an action. The key can contain letters, numbers and underscores, and later steps use it in templates. The actions are:

Every parameter and output is listed in Step types. For ready-made patterns, see Workflow recipes.

Passing data between steps

Parameters can contain templates in double braces. Anythink resolves them just before the step runs.

When a template is the whole value of a JSON field, the value keeps its type, so a number stays a number and an object stays an object. Inside longer text it's written into the text. If a path doesn't resolve, the expression is left as written, so add a fallback with | default:

{{ $anythink.trigger.data.nickname | default: "there" }}

The full rules are in Template syntax.

Success and failure paths

A step succeeds when its action completes and fails when it doesn't. A failure might be a rejected parameter, a script error, or a non-2xx response from a Call An API step. A Condition step that evaluates to false counts as a failure too, which is how you branch: link on success to the "true" path and on failure to the "false" path.

Plan the "nothing to do" outcome. If a Condition is false and has no on failure link, the job ends Failed. Link the false branch to a step, even a harmless one, when that outcome is normal.

Retries

Anythink doesn't retry anything. A failed step either follows its on failure link or ends the job, and a failed job stays failed. To run it again, trigger the workflow again with the same payload. The job history keeps the payload you need. To react to a failure instead, send yourself an email or a message from the on failure path.

Jobs and history

Every run is recorded in the workflow's Job History, so you can see exactly what each step received and returned.

A job keeps the payload that started it, an error message if it failed, and for every step that ran its success flag, log, output and error. Open it in the Anythink dashboard from View Job History in the workflow editor, or list a workflow's jobs with anythink workflows jobs <workflow_id>. To try a workflow without waiting for its trigger, use Test Workflow in the editor, or run anythink workflows trigger <workflow_id> --payload '<json>'. The payload appears as $anythink.trigger.data. Test workflows and read job history covers reading jobs and tracking down failures.

Who a workflow acts as

Workflow steps run as the Anythink workflow worker, a trusted service, not as the person who started the job. Design for two consequences:

• Reads ignore row-level security. A Read Data step sees every record in the entity. Filter explicitly to the user or group you're acting for, for example user_id equals {{ $anythink.trigger.data.user_id }}.
• Records created by a workflow have no owner. On entities with row-level security, grant access in the step itself with its row-level security options. See Step types and Groups and row-level security.

Anyone who can edit a workflow can therefore read and send any data in the project. Give the workflow permissions (anythink_workflows:create, :update, :delete and :trigger) only to people you'd trust with that access. See Roles and permissions.

Limits

Behaviour worth knowing

• Workflows can trigger workflows. Create Data and Update Data steps write through the normal API, so they fire event triggers, including on the entity the workflow itself watches. Use a trigger filter to stop a workflow from starting itself again.
• A step that runs twice replaces its output. If your links loop back to a step, later steps see the most recent run's output.
• Several workflows can watch the same event. Each one starts its own job.

Next steps

• Build your first workflow: build and test one in about ten minutes
• Triggers and scheduling: events, filters, schedules, manual buttons and API routes
• Step types: every step, parameter and output
• Template syntax: every {{ }} expression a step accepts
• Test workflows and read job history: read jobs and fix failures
• Webhooks: start a workflow from an HTTP call, or call another system
• Secrets: keep API keys out of your steps