Test and monitor workflow runs
Preview a workflow with a write-free safe test, run it live once with Run now, or activate it to run on its own, then watch every run step by step and retry only what failed.
Before you start
- A workflow that passes its checklist, so Save, Run and Activate are available.
A workflow only becomes trustworthy once you have watched it run. Spiich gives you three ways to start one, from safest to most permanent, and a run view that shows exactly what happened at every step.
Preview first, Run now, and Activate
| Action | What it does | CRM changes and Slack messages |
|---|---|---|
| Preview first | Runs a sample of up to 5 records and saves exact Slack previews | No CRM writes or Slack sends |
| Run now, confirmed live | Starts one run against live data | Can write CRM data and send permitted messages |
| Activate | Makes the saved version eligible for its configured starts | Future live runs can write and send |
Choose Run now, then Preview first to check the workflow before sending. Unsaved edits are saved as a new version first. A preview still uses credits when an agent works. When a Slack delivery step or tool is reached, the run stores the exact recipient and message, or a blocked outcome explaining why delivery is unavailable. A step that never reaches a delivery action has no saved message preview.
Inspect that preview before confirming a live run. A live run executes the workflow again: an agent can generate different text from the preview. There is no approval that freezes the preview and sends that exact copy later.
The live confirmation describes the changes and recipients. Stopping a run does not undo CRM changes or retract Slack messages already delivered, and an in-flight send may still complete.
Activate hands the workflow over to its own schedule or table trigger. The confirmation states in plain words when it will run from now on, the schedule in English with its timezone, or that nothing fires on its own if the trigger is Manual, and what each run can change, for example "Each run can add and update CRM records and write notes on them." Activation is refused if the current version fails validation.
Watching a run
Open any run from the workflow's Recent runs list, or from the sidebar. The run replays as the same graph you built: each step lights up as it is reached, and you can see which record is currently being worked, how many are done, how many remain, elapsed time, and credits used so far. Click any step to see exactly what happened there, including an agent's output and what it wrote to the CRM.
A side panel gives you the outcome in plain words, the counts that actually happened (records fetched, processed, enriched, partial, skipped), Run details (Started, Duration, Started by, Version), and a list of recent runs so you can compare. Open technical report goes deeper for anyone who wants the raw detail.
A run's status is one of Waiting, In progress, Paused, Finished, Needs attention, Couldn't finish, or Stopped.
Reading Slack delivery outcomes
Open a step, including a step inside a batch item, to see its message card. It shows the recipient, exact text, a copy control and the delivery result:
- Preview: the message was saved for inspection and was not sent.
- Sent: Slack returned a confirmed receipt. Open in Slack opens that message.
- Not sent: read the reason, such as missing recipient permission, a disconnected workspace, or an unavailable destination.
- Unconfirmed: delivery could not be confirmed. Check Slack before starting another run; the message might already be there.
An agent finishing its reasoning does not prove that its message arrived. In a batch, inspect each item: two successful items and one failure leave a partial run. Retrying the failed item preserves the successful items and their saved results.
Pausing, resuming and stopping
Open the active run
It shows a spinner in Recent runs while it is going.
Pause, resume or stop it
Pause finishes whatever step is already under way and starts nothing new until you resume. Stop asks first: queued work stops, a step already in progress may still finish, and CRM changes already applied are not undone.
Read what survived
A stopped run keeps everything it already completed. Nothing is lost, and nothing already written is rolled back.
Retrying only what failed
A finished run with failures offers Try the failed steps again on the run summary, or on an individual failed step. Successful steps and their receipts are reused. Failed work can still use credits when retried. You can also retry within one failed record's scope.
Slack duplicate suppression applies to the same recipient and repeated message within one step execution in one run. A confirmed duplicate reuses its receipt, and the message card shows the suppressed repeat. Different items, different steps and new runs can send again. This does not suppress duplicate trigger events across runs. An uncertain delivery attempt is held for investigation rather than automatically sent again.
Reading a failure
When a run fails, the run view names the exact step that stopped it and translates the underlying problem into plain words instead of a raw error. Common ones include the workspace running out of credits, something taking too long and timing out, missing permission to do the work, a connected service being busy, a step with no CRM record to write to, or a record filter Spiich cannot read.
You can also hand a failed step straight to the assistant: open the run, select the failed step, and use the ask-the-assistant action on it. It already has the run, the step, the record it failed on and the reported error, so you can just ask why it failed and what to change.
Credits and running out mid-run
Agent steps run on usage-based credits, charged as they run, which is why safe tests still use credits even though nothing is written. If a run stops because the workspace cannot spend, the run view says so in plain language and links straight to billing rather than offering a retry that cannot succeed: Add credits, then try again on the run summary, or Add credits in billing on the failed step, both of which go to Settings > Billing.
Building and testing a workflow by talking to the assistant
You can describe a workflow to the assistant in Chat instead of building it on the canvas by hand. Say what you want, for example "every Monday go through my accounts that have gone quiet and research them," and the assistant opens a new workflow beside the conversation as an artifact and builds it up step by step, showing which step it is touching as it works. Keep chatting to ask for changes, or switch to the canvas and edit it directly.
The assistant can also open an existing workflow by name, read its steps and settings, make targeted edits and save a new version, and list or inspect past runs. It can start a safe test on your behalf and report what happened.
You can also start a live run through chat after explicitly confirming the proposed CRM changes and Slack recipients. The agent must explain these effects and obtain your confirmation before starting. Scheduling future runs through Activate is a separate action.
If something goes wrong
A run has said "In progress" for hours and never finishes. It stalled. Open it and click Stop. Everything it already completed stays readable.
"Could not load runs" or the run history will not load. Usually a brief unavailability during a deploy. Click Try again; nothing already recorded is lost.
A step reports "This step had no CRM record to write to." A note or update step points at a value that did not resolve to a record. Reopen the step and re-pick the record from the dropdown of values earlier steps produced, rather than typing a reference by hand.
A run's summary looks fine but the workflow "Couldn't finish." The failing step usually sits outside the per-record loop, like the step that fetches the records in the first place. Read the run summary; it names the exact step and explains why in plain words, then use Try the failed steps again.