Test workflows and read job history

Every run of a workflow is a job. Anythink keeps the payload that started it, the status, and for every step that ran its log, output and error. That history is how you test a workflow and how you find out why one failed.

This page shows each task in the Anythink dashboard, with the CLI and with an AI assistant. For the model behind it (triggers, steps, success and failure paths), read How workflows work.

Test a workflow

A test run starts a job straight away, without waiting for the trigger. You choose the payload.

anythink workflows trigger 256 --payload '{"total":150}'

✓ Workflow 256 triggered.

anythink workflows trigger 256 --entity orders --entity-id 1042 --payload '{"total":150,"status":"paid"}'

Run workflow 256 with the payload {"total":150}, then show me the job.

What a test run does

A test run creates an ordinary job. It uses the type of the workflow's first enabled trigger, so the workflow needs at least one enabled trigger or the call is refused with Workflow has no enabled trigger.

• The payload is yours. The job starts with { id, entity_name, data } built from what you sent, and a trigger filter isn't checked. Your steps read it as $anythink.trigger.
• Timed workflows run once, immediately. The schedule isn't touched, so the next scheduled run still happens when it was due.
• It needs the right permission. Starting a workflow takes anythink_workflows:trigger.

Read a job

Open a job to see exactly what it received, what each step did and why it ended as it did.

anythink workflows jobs 256

anythink fetch /workflows/256/jobs/133261

{
  "status": "Success",
  "payload": "{\"id\": 1, \"data\": {\"total\": 20, \"status\": \"new\"}, \"entity_name\": \"orders\"}",
  "error_message": "",
  "steps": [
    {
      "success": false,
      "error_message": "Condition evaluation failed - no data items matched the specified conditions",
      "log": "…",
      "data_json": "{\"condition_result\": false, …}",
      "workflow_step": { "key": "check_total", "name": "Check total", … }
    },
    {
      "success": true,
      "log": "Starting RunScriptAction for step log_low\n…",
      "data_json": "{\"data\": [{\"skipped\": true}]}",
      "workflow_step": { "key": "log_low", … }
    }
  ]
}

Show me the latest jobs for workflow 256 and what each step returned.

Job numbers and job ids

The dashboard numbers a workflow's jobs from 1, oldest first, so Job #3 is the third run of that workflow. The API and the CLI use the job's id, which is unique across the project. To match one to the other, compare the payload and the time.

Job statuses

Read a failure

A step fails when its action doesn't complete: a script error, a rejected parameter, a non-2xx response from Call An API, or a Condition that evaluates to false. What happens next depends on whether the step has an on failure link.

To find the cause of a Failed job:

1. Read the Error box. It is the message from the step that failed.
2. Find the step with the Failed badge under Execution Steps. Open its Logs tab for what it did before it stopped, and its Data tab for what it saved.
3. Compare the step's inputs with the job's Payload. Most failures are a template that points at a field the payload doesn't have.

For example, a Run Script step that reads a field the payload doesn't carry ends the job like this:

{
  "status": "Failed",
  "error_message": "Cannot read properties of undefined (reading 'rate')",
  "steps": [
    {
      "success": false,
      "error_message": "Cannot read properties of undefined (reading 'rate')",
      "log": "Starting RunScriptAction for step read_discount\nPreparing JavaScript engine (Memory: 64MB, Timeout: 30s)\nExecuting script\n",
      "data_json": null,
      "workflow_step": { "key": "read_discount", … }
    }
  ]
}

A Call An API step that gets a non-2xx response saves the response and status_code in its Data tab. A Condition step saves every comparison it made, with the expected_value and actual_value, so you can see why a branch went the way it did.

Why didn't my workflow run?

Give steps descriptive keys (find_due_orders, not step_2). Keys appear in templates, in logs and in the job's current-step field. In a Run Script step, console.log writes to the step's log, which helps while you build.

Rerun a failed job

Anythink doesn't retry a failed job, and there is no rerun button. To run one again, start the workflow with the same payload. The failed job stays in the history, and the rerun is a new job.

anythink workflows trigger 257 --entity orders --entity-id 2 --payload '{"total":300,"status":"fail"}'

Run workflow 257 again with the payload from its last failed job, then show me the new job.

What a rerun repeats

A rerun starts at the start step. Steps that succeeded the first time run again, so a step that created a record creates another. Fix the cause first, then rerun, and check what the earlier steps wrote before you do.

Disable a workflow

A disabled workflow stops reacting to its event and timed triggers. Nothing is deleted, and you can switch it back on at any time.

anythink fetch /workflows/256/disable --method POST
anythink fetch /workflows/256/enable --method POST

Disable workflow 256.

Get told when a job fails

Anythink doesn't send an alert when a job fails. Build one with the workflow's own failure path: link the step's on failure handle to a Send an Email or Send a Push Notification step, and the failure reaches you the moment it happens. Because the failure is then handled, the job ends Success and the step keeps its Failed badge, so open the job to see which step failed.

anythink workflows step-link 257 648 --on-failure 649

In workflow 257, make step 649 run when step 648 fails.

Jobs from the API

GET /org/{project_id}/workflows/{workflow_id}/jobs?page=1&pageSize=25
GET /org/{project_id}/workflows/{workflow_id}/jobs/{job_id}

Both need anythink_workflows:read. The list is newest first and returns items, page, page_size, total_items, total_pages and the paging flags. Each job has its status, payload, error_message, current_executing_step_key and a steps list with every step's success, log, data_json and error_message. The list includes the steps, so use a small pageSize when you only need statuses.

Permissions

Project administrators have all of these. Job history shows what every step received and returned, so give anythink_workflows:read only to people you trust with that data. See Roles and permissions.

Limits

Next steps

• How workflows work: triggers, steps, templates, jobs and limits
• Triggers and scheduling: events, filters, schedules, manual buttons and API routes
• Step types: every step, parameter and output
• Build your first workflow: build and test one in about ten minutes
• Workflow recipes: ready-made patterns