Skip to main content
A run is one execution of a published workflow. The run viewer records every input, output, and error so you can operate workflows like production software. A workflow edits your CRM on every run. So treat each run as something you can ship, watch, and trace. That habit is the difference between a tidy pipeline and a Friday afternoon spent undoing 400 bad writes. This page covers the operational side of a workflow. You will learn how a draft becomes live, how to read a single run in the viewer, how to trace a failure back to its true cause, and how to recover with rerun, retry, pause, and cancel. By the end you can publish a change without disturbing runs that are still in progress. You can also find the real cause of a red error that shows up three blocks past the actual bug. And you can decide whether a failed run is safe to retry from the failed block, or whether it needs a fresh trigger. The run viewer sits on every workflow’s Runs tab. It is the first place to look when something fired, and the second place to look when something didn’t.

​
Publishing a workflow

A workflow does nothing until you publish it. You build on a draft canvas, which is a private working copy. No trigger fires until you click Publish. Once a workflow is live, further edits stay in draft until you click Publish changes. You can also click Discard changes to throw the draft away and go back to the live version. Publishing validates the canvas first. A misconfigured block gets a red error indicator and blocks the publish until you fix it. Consider a workflow that watches the deals object and posts to #revenue on a stage change. You add a Filter block to skip test deals, then publish the change. The new version goes live as v4. Every run triggered from this moment uses the filtered logic. One rule surprises people: in-flight runs finish on the version they started on. A run that began before your edit completes on the old logic. This matters most when a Delay block parks a run for days. That parked run finishes on whatever version was live when it started, not the version you just published.
Set the workflow timezone on the Settings tab before you publish anything date-sensitive. Every date and time operation in the run uses it, and the default is rarely the one your RevOps brain assumes. Failed-run email notifications are also configured on the Settings tab. They are on by default for workflows you create, and capped at one email per failure reason per day.

​
Reading a run

The Runs tab lists every execution of a workflow. Click one and the canvas becomes a frozen snapshot of exactly what happened on that run. Green arrows mark the path that ran, green checks mark successful blocks, and a red icon marks the failure point. The sidebar carries the run-level facts. Hover a run to see its runtime, start and end times, and the credits consumed, which is your per-run cost meter. Suppose a run on the people object failed while creating a task for Priya Sharma. You open the run and inspect the blocks in order. The red icon sits on Create task, but its Inputs panel shows an empty assignee. That points upstream, to where that value should have been set. Click any block to open two panels. The Inputs panel shows what the block received. The Outputs panel shows what it passed on. A Loop block adds < and > arrows so you can step through each iteration. An agent block expands to show each step the agent took and what it produced. Reading these panels in order is the whole skill. The run viewer never hides what a block saw or what it returned.

​
Tracing a failure to its cause

A failure usually surfaces downstream of where it starts. The red icon marks the block that could not proceed, which is not always the block that broke. Tracing means walking backward from the symptom to the point where things first went wrong.
  1. Open the failed block and read both the error message and its Inputs.
  2. Decide whether the input is wrong or the block itself is misconfigured.
  3. If an input looks wrong, open the upstream block that produced it and read its Outputs.
  4. Repeat until you reach the block where expectation and reality first diverge. That block is the bug, regardless of where the red icon sits.
In the Priya Sharma example, the error surfaced on Create task. Tracing the empty assignee upstream reveals a Find records block that returned a person with no owner. The fix belongs there, not on the block that turned red. The exact error strings and their remedies are catalogued in Common errors.

​
Rerunning and retrying

Every run offers a way to run it again, and the two paths are not interchangeable. A successful run offers Rerun, which executes the whole workflow again with the original trigger data. A failed run offers Retry, which gives two choices.
  • Retry from start re-executes the entire workflow from the trigger with the original data.
  • Retry from failed resumes at the failed block and skips the blocks that already completed.
Reach for Retry from failed when the failure was transient, such as a brief outage at an external API, and the earlier blocks already wrote data. Resuming from the failed block avoids re-running the successful writes and double-writing records. Imagine a Send HTTP request block that timed out after an Update record block already set a deal to Closed Won. Retrying from start would set the stage twice. Retrying from the failed block runs only the HTTP call. Two facts govern every retry. First, a retry runs the workflow version that was published when the run originally triggered, not your fixed version. To verify a fix, you must trigger a new run. Second, attempts stack under the same run behind an Attempt dropdown, so you can compare the before and after of the same execution. What does not happen is automatic retry. The new engine does not retry failed runs on its own. A failed run stays failed until a human acts. This is why the failure-notification emails matter. It is also why anything business-critical deserves a periodic “did this actually run” check. On cost, failed blocks consume no credits, but every block that succeeded before the failure does. So a retry-from-start re-bills the work the retry-from-failed would have skipped. For the full credit math, see Credits & pricing explained.

​
Pausing, resuming, and cancelling

A run in progress can be paused, resumed, or cancelled. Pause lets the current block finish, then halts before the next one. Resume continues from where the pause stopped. Cancel is permanent: the current block still completes and bills, but nothing after it runs. Pause is the most underused control in the engine. Say you spot bad data mid-run, such as a Find records block that returned 4,000 companies instead of 40. Pause the run, open the offending block, and read its Inputs and Outputs. Only then decide whether to resume or cancel. Pausing turns a panic into a diagnosis. You act on full information instead of guessing while writes pile up.

​
Running a pre-publish check

Thirty seconds of checks before you click Publish prevents most incidents. Run through this list every time. Run through it twice for any workflow that writes to the object it triggers on.
  1. Is the trigger scoped to a specific attribute where possible, with an early Filter to drop records you don’t want? See Conditions & filters.
  2. Is there a loop guard if the workflow writes to the same object it triggers on?
  3. Are all variables wired with no yellow warnings, and do formula inputs have fallbacks?
  4. Are write permissions granted on both sides of every relationship the workflow touches?
  5. Have you estimated the worst-case run cost with the credit math, and set the Loop Limit while testing?
  6. Have you test-triggered the workflow once and traced that run in the viewer?
A workflow that passes all six is one you can publish without watching it. A workflow that fails any of them is one you’ll be debugging in the Runs tab within the hour.
Deleting a workflow cancels all in-flight runs immediately and is permanent. Disabling stops only new runs and lets in-progress ones finish. Archiving pauses the workflow the same way. A workflow that has ever run can only be archived, never deleted. So for anything that has fired even once, archive instead.

​
See also

Source: Attio Help Center: Overview of workflows, Create a workflow, and Troubleshooting workflows. Last reviewed against the Attio Help Center, June 2026.