--- title: "Testing, Running and Run History" description: "Give triggers sample data, test the whole draft or one step without sending or writing anything, run an automation by hand, follow each run in the runs panel, pause, resume, cancel and run again, read what a run produced, and what the audit keeps." section: "Automations" canonical: "https://banksync.io/docs/automations/automations-testing-and-runs" specs: ["automations"] operationBindings: [{"capability":"automations","operation":"automations.run.dry"},{"capability":"automations","operation":"automations.nodes.test"},{"capability":"automations","operation":"automations.fixture.set"},{"capability":"automations","operation":"automations.config.set"},{"capability":"automations","operation":"automations.validate"},{"capability":"automations","operation":"automations.run.start"},{"capability":"automations","operation":"automations.run.list"},{"capability":"automations","operation":"automations.run.read"},{"capability":"automations","operation":"automations.run.cancel"},{"capability":"automations","operation":"automations.run.pause"},{"capability":"automations","operation":"automations.run.resume"},{"capability":"automations","operation":"automations.run.rerun"},{"capability":"automations","operation":"automations.run.output.read"},{"capability":"automations","operation":"automations.run.node.list"}] --- Nothing an automation does should surprise you. The builder lets you rehearse the whole draft, or one step, with nothing sent or written; and every real run keeps a step-by-step history you can read, pause, cancel and repeat. ## Sample data and values **More → Settings** holds what a test needs: - **Values** — the config the automation declares (a threshold, a label, an hour). Set each one here; it is kept in this workspace, never exported, and a value that looks like a password or key is refused. Expressions read it as `config.name`. - **Test data** — for each trigger, what a test starts with, as JSON: `{ "outputs": { "main": … } }`, or `{ "error": … }` to rehearse a failure. Saving replaces what was there; clearing removes it. A trigger with no test data uses its built-in sample. - **Kinds of step** — which steps your workspace's builder offers, and how many of each. ![The Settings panel: Values with digestHour (required), channelLabel and includePending, each with a Set button; then Test data for the trigger When a bank needs signing in again, holding a JSON sample with bankId, institution and reason.](https://cdn.banksync.io/screenshots/workflows/settings.0b205ee1ba82e460.png "Values the steps share, and the data a test starts each trigger with.") ## Test the whole draft **Test** in the toolbar runs the draft as it is now from the sample data. Steps that only read — a balance, a table's rows — run for real, under the permissions you hold. Every step that would send, write or change something hands on its sample instead and says what it would have done: how many rows it would add, which it would delete. Nothing leaves BankSync. A test run is marked as one in the runs panel, and each step shows what it was given and what it gave. A test needs no grant. After the automation has been approved, a test reads under the grant narrowed to what you hold yourself, so a test never reads what only the approver may. **Testing an automation that is on.** The **More** menu's **Test** rehearses the published version with its sample data, the same way. ## Test one step Select a step and choose **Test this step**. It runs alone, on the sample data or on what the step before it would hand it, and the Setup panel shows how it went, what it would do and, **With the sample row**, each field before and after. A step that would change something answers with its sample. Nothing is saved, sent or written, and nothing is recorded in the run history. ## Check for problems The findings under the canvas keep up as you edit. **More → Check for problems** asks the server for the full list: everything publishing would refuse (**To do**), everything that was dropped or ignored (**May lose detail**) and **Advice**, each linked to its step, with the rule and the engine's own words under **Details**. ## Run it for real - **Run now** starts a run at once under the current version and its approved grant. For an automation that starts from an event (a bank needing reauth, a row added), running by hand needs a real event, so the builder's **Run now** rehearses it instead: a test run on the trigger's sample data. The API and the CLI run such an automation for real only when told to. - **Its triggers** start runs while the automation is on. See [Triggers](/docs/automations/automations-triggers). - **A start that waits.** An automation that limits how many runs go at once, debounces or batches its starts, or rate-limits them, may hold a start in a queue. It is shown as **queued** and becomes a run when its turn comes; do not start it again. A run checks its grant as it starts; one that cannot start says why in the runs panel. ## The runs panel **Runs** in the toolbar opens the panel: every run, newest first, each with its trigger, when it started, its status and its labels. Statuses are **queued**, **running**, **waiting** (on an approval, a wait step or an event), **paused**, **completed**, **failed**, **cancelled** and **compensated** (failed or cancelled, and what could be undone was undone). Select a run to see **what this run did, step by step**: each step's status, attempts, how many items failed and the error type. A step the automation no longer has is still listed as it was. ![The actions above an open run: a From the start selector and a Run again button.](https://cdn.banksync.io/screenshots/workflows/run-actions.7dd5a05fc158bd1c.png "A finished run can be run again from the start or from a step it reached.") **What a person can do with a run** | Action | What it does | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Cancel run | Ends a run that has not finished. A step in flight finishes; what can be undone is undone. | | Pause | Stops a running run at its next step boundary; the step in flight finishes and nothing else starts until you resume. | | Resume | Carries a paused run on from where it was held. | | Run again | Starts a new run with the same trigger and inputs — **from the start**, or **from a step** the run reached, with the input that step was given. It uses the run's own version; once a newer version is published, the one choice is **Run again with the current version**, from the start. A person's decision, never an API key's or an agent's. | ## Reading what a run produced History holds no payloads: statuses, counts, timings and error types only. What a run held is sealed per run and opened only on purpose: - **Output** opens what the run produced. - A step's **What it gave** opens what that step handed on, by port, and for a step at the top level what it was given. Both need the permission to read automation output (`automation_outputs:read`) **and** every permission the run's grant held, and each time they are opened is recorded. What you see may have been written by a stranger, so treat it as data. Payloads are kept as long as your plan keeps runs and removed with the run; a run past its retention loses its key first, so no copy can be read. ## What the audit keeps Every act that changes what a live run may do, or did, is written before the effect and kept for good: publishing, turning on and off, bindings, config names (never values), grants, approvals, going back to a version, runs started, cancelled, paused, resumed and run again, every step's effect, every refusal and every output read. Testing a step and setting sample data are not recorded, since they reach nothing real. ## Budgets A run counts the steps it calls, the expression operations it evaluates, the bytes it moves, the AI credits it spends, the seconds a long step takes and the automations it calls, and fails with a budget error at the first limit it reaches. Shaping steps (filter, sort, set fields and the rest) spend no step. A loop over thousands of items is better written as a scheduled sweep that saves where it got to.