Every run of a workflow is a job, and Anythink keeps each job's payload, status and step-by-step results. That history is how you test a workflow and how you find out why one failed.

Test a workflow

In the Anythink dashboard

Open the workflow and select Test Workflow.
Choose an entity and a record to use as the trigger data, or edit the JSON payload directly.
Run it. The canvas highlights each step as it runs: running, succeeded or failed.
Select View Job History to see the job in full.

With the CLI

bash

anythink workflows trigger 174
anythink workflows trigger 174 --payload '{"total":129.5,"status":"paid"}'

Limit: The CLI prints API error (204): Empty response even when the job was queued successfully — a 204 No Content is the documented success response, not an error. Check Job History, or anythink workflows jobs <id>, to confirm the run.

What a test run does

A test run works the same way for any trigger type, including timed workflows, which run once immediately without affecting their schedule.

Note: Test runs are real runs. Steps write data, call APIs and send email and push notifications. Test against sample records, or disable steps with side effects by routing around them while you build.

Job statuses

Status	Meaning
`Pending`	Queued, not started
`Running`	The worker is running its steps; the job shows the current step key
`Success`	The last step it ran succeeded, or a failure was handled by an on failure path
`Failed`	A step failed with no on failure link, the job hit a limit, or the project's workflow quota was used up

Reading a job

Job History lists the workflow's jobs, 25 per page, newest first. Open a job to see:

Payload: the id, entity_name and data the job started with.
Error: the message from the step that failed the job.
Each step's log: what the step did, including resolved queries, request URLs and condition values.
Each step's data: the output saved for later steps, or the failure details — for example the HTTP status and response from Call an API, or every comparison a Condition evaluated.

The job view refreshes every two seconds while a job is running.

Jobs from the API

http

GET /org/{orgId}/workflows/{workflowId}/jobs?page=1&pageSize=25
GET /org/{orgId}/workflows/{workflowId}/jobs/{jobId}

Both need anythink_workflows:read. Each job includes its status, payload, error_message, current_executing_step_key and a steps list with every step's success, log, data_json and error_message.

anythink workflows jobs <id> calls the same endpoint, but its list view doesn't surface that detail yet:

text

── Jobs (1) ────────────────────────────────────────────────────────────────────

  Job #133086 Success — ?

The ? stands in for fields the CLI doesn't render (payload, error message). Use anythink workflows step-get <workflow_id> <step_id> for a step's parameters, or call the API endpoints above directly for the full job, including each step's data_json.

Limit: anythink workflows list currently crashes with Value cannot be null. (Parameter 'text') once the project has a workflow with certain malformed trigger configuration. Use anythink workflows get <id> for a single workflow, or call GET /org/{orgId}/workflows directly, until this is fixed.

Re-running a job

Failed jobs aren't retried automatically. To run one again with the same input, copy the job's payload and start the workflow with it:

http

POST /org/{orgId}/workflows/{workflowId}/trigger
Content-Type: application/json

{ "entity_name": "orders", "entity_id": 1042, "data": "{\"total\":129.5,\"status\":\"paid\"}" }

data must be the payload's data as a JSON string. See Triggers and scheduling.

Why didn't my workflow run?

Symptom	Check
No job appears for an event	The workflow and trigger are enabled, the event and entity are right, and the trigger filter matches. Filtered-out events leave no job.
A timed workflow never runs	The cron expression is valid and written in UTC
A job failed with a quota message	Your plan's monthly workflow runs are used up
A job failed at a Condition	The condition was false and has no on failure link. Link the false branch.
A value shows up as `{{ … }}` in a record or message	The template path doesn't exist: check the step key, `data[0]`, and field names
A step can't find records you can see in the dashboard	Workflow reads aren't limited by row-level security, but filters are exact. Check the filter values in the step log.
Users can't see records a workflow created	Grant access with the row-level security options on the create step
An integration step fails with "No credentials found"	Connect the service in Settings › Integrations
A job failed with "exceeded maximum step limit"	Your links form a loop. Jobs stop after 250 step executions.
A workflow runs again and again	A step writes to the entity that triggers the workflow. Add a trigger filter so the workflow's own writes don't match.

Keep logs useful and safe

Step logs record resolved values, including request URLs. Send credentials in headers or integration connections, never in URLs or query strings.
Use console.log in Run a script steps to record intermediate values while you build, and remove noisy logging once the workflow is stable.
Give steps descriptive keys (find_due_orders, not step_2): keys appear in templates, logs and the job's current-step field.

Permissions

To	Permission
View workflows and job history	`anythink_workflows:read`
Create workflows and add steps	`anythink_workflows:create`
Edit, enable and disable	`anythink_workflows:update`
Delete	`anythink_workflows:delete`
Start a workflow by API or button	`anythink_workflows:trigger`

Project administrators have all of these. API keys need the exact permissions for the calls they make.

Next steps

How workflows work Workflow recipes

Monitoring and testing