Troubleshooting workflows
Learn how to monitor and fix issues with your workflows.
If you're working with legacy workflows, see Troubleshooting legacy workflows instead.
Troubleshooting helps you understand why a workflow did not run as expected and identify where an error occurred. The run viewer shows each run step by step so you can inspect block behavior, review run data, and diagnose failures. You can also rerun failed executions, compare retry attempts, and troubleshoot common configuration issues.
Access the run viewer
The run viewer shows a complete history of your workflow runs.
From the Workflows page, open the workflow you want to troubleshoot.
Click the Runs tab.
Browse the list of runs and click a run to view its details.
Run viewer overview
The run viewer has two sections: a read-only workflow canvas on the left and a sidebar on the right.
The sidebar shows summary details for the selected workflow and a list of all runs. By default, the most recent run is selected. Hover over a run to reveal the runtime, start and end times, and the number of credits consumed.
Click a run to open the workflow canvas for that execution and show the blocks as they appeared when the run happened. Green arrows indicate the path that executed. Green checkmarks indicate blocks that executed successfully, and failed blocks are marked in red.
Inspect block inputs and outputs
Click any block in a completed run to see a detailed view of that block’s execution in the sidebar. Scroll down to find Inputs and Outputs.
Inputs show the values that were passed into the block when it executed.
Outputs show the data that block passed to later blocks in the workflow.
For example, a Formula block displays its calculated value, and a Create record block shows the created record along with who created it and when. Not all blocks display outputs.
Use inputs and outputs together to trace where something went wrong:
Start with the block that failed or behaved unexpectedly.
Check that block’s Inputs to see what data it received.
Then open any blocks it pulled data from and review their Outputs.
Compare the two to see whether the issue came from the input data, the block configuration, or the block’s logic.
This is often the fastest way to diagnose a workflow. In many cases, the error starts in an earlier block, even though it only becomes visible later in the run.
Identify failed blocks
Any block that failed is highlighted in red on the canvas. Click a failed block to display a detailed error message in the sidebar. Failed blocks do not count toward credit usage.
For common errors and how to fix them, see Common error messages below.
Navigate loop iterations
If your workflow contains a Loop block, use the < and > buttons above the block on the canvas to step through individual iterations. This helps you identify whether a failure occurred on one specific iteration or across all of them.
This is especially useful when a loop succeeds for some iterations but fails for others.
View agent results
If your workflow contains an agent block, click the block to show each step the agent took, the questions it investigated, and the outputs it produced. If the agent could not find an answer to a question, that question’s output will be empty.
Rerun or retry a run
You can execute any completed run again from the run viewer.
Open the workflow and click the Runs tab.
Select the run from the list.
Click Rerun to run a successful run again, or click Retry for a failed run and select one of the following options:
Retry from start re-executes the entire workflow from the beginning using the original trigger data.
Retry from failed re-executes the workflow starting from the block that failed and skips blocks that already completed.
Note: Retrying a run always uses the version of the workflow that was published when the original run triggered, not the currently published version.
After rerunning or retrying, a new attempt is created under the same run. Click the Attempt dropdown next to the run number to switch between attempts. Each attempt shows its status and execution time so you can compare results across retries. This helps you confirm whether a change fixed the issue or whether the failure is still occurring in the same place.
Pause, cancel, or resume a run
While a run is in progress, you can use the toolbar at the top of the run viewer to pause, resume, or cancel it. From here you have these options:
Pause temporarily stops execution. The currently executing block completes before the run pauses. Use this if you want to investigate an issue mid-run before the workflow continues.
Resume continues a paused run from where it stopped.
Cancel permanently stops execution. The currently executing block still completes and counts toward credit usage, but no further blocks execute or consume credits. Use this if you know the run should not proceed.
Resolve common workflow issues
These are some of the most frequent workflow issues and how to resolve them.
Prevent infinite loops
A common issue occurs when a workflow updates a record in a way that triggers the same workflow again, or when two workflows repeatedly trigger each other. For example, a workflow triggered by Record updated that also updates the same record could trigger itself repeatedly.
There are a couple of ways to prevent this:
Filter out workflow-initiated updates. Add a Filter block immediately after the trigger with a condition Updated by > Type > is not > Workflow. This ensures the workflow ignores updates made by any workflow automation. This filter applies to updates from all workflows, not a specific workflow.
Scope the trigger to a specific attribute. For Record updated, List entry updated, and Attribute value changed triggers, configure the trigger to run only when a specific attribute changes that your workflow's actions do not modify. For example, if the workflow updates Deal owner, scope the trigger to run only when Deal stage changes.
An attribute update isn't triggering a workflow
If a workflow uses a Record updated or List entry updated trigger but does not fire when you expect it to, the attribute value may have been set during creation rather than updated afterward. These triggers fire only when changes happen after the record or list entry is created. If the attribute value is set at creation time, such as a deal created with the stage already set to “Won,” the trigger does not fire because the value was never updated.
To catch attribute values set at creation time, use the Attribute value changed trigger instead. This trigger fires whenever the specified attribute's state changes, including values set when the record or list entry is first created.
Filter conditions are returning unexpected results
If filter conditions are not working as you expect, check the operators between your conditions. Conditions joined by and require every condition to be true, while conditions joined by or require only one to be true. When conditions are organized into groups, verify the operator both within each group and between groups. Learn more about setting filter conditions and using condition operators.
For example, a filter that checks “Deal stage is Won” or “Deal owner is Alex” will match records that meet either condition, while and matches only records that meet both.
A block is only processing one record or list entry
If a block is connected directly to the output of a Find records or Find list entries block that returns multiple records or entries, the block processes only the first result by default. This is usually indicated by a warning icon on the block.
To process every matching record or list entry:
Add a Loop block after the Find records or Find list entries block.
Configure the Loop block to iterate through the returned records or list entries.
Place the block you want to run for each result inside the Loop block.
This ensures the workflow takes action on each returned record or list entry instead of only the first one. Learn how to use Loop blocks.
Resolve common error messages
When a block fails, the error message in the run viewer indicates what went wrong. Here are common errors and how to resolve them.
“The provided sender has not enabled delegated sending”
This error occurs when delegated sending is not enabled for the sender used in your workflow’s sequence. To fix it:
Go to Sequences in the main sidebar and open the sequence used in your workflow.
Open the Settings tab at the top.
If you want to send emails from your own address, enable the toggle for Enable delegated sending.
If you want to send emails from someone else’s address, search for and invite them as a delegated sender. They’ll receive a notification to approve the invite before emails can be sent from their address.
Once delegated sending is enabled for the sender used in your workflow, the error should no longer appear. Learn more about delegated sending.
“Company records cannot be enrolled into a sequence” or similar
Sequences send to people, not companies. Only person records can be enrolled in sequences as recipients, and they must have an email address to enroll successfully. If the record you were trying to enroll is not a person, consider whether it is connected to a person via a relationship attribute. If so, use a variable to select the person via the relationship attribute for the Recipient input.
If the relationship attribute may hold more than one person and you want to enroll all of them, add a Loop block before the Enroll in sequence block and place the Enroll in sequence block inside the Loop. Learn how to use Loop blocks.
“Step took too long to execute”
A block exceeded the 2-minute maximum execution time. This can affect the Send HTTP request block when an external service is slow to respond. Check whether the external endpoint is available and responding within the time limit. If the service requires more processing time, consider breaking the request into smaller operations. Retry the run if the delay was temporary.
“This workflow does not have permission to write for this object”
This appears when a workflow can read from an object but has not been granted write access to update it. Workflows do not automatically inherit write access to every object. To fix this, a workspace member with full access or admin permissions for the relevant object needs to give the workflow access to the object.
Note: To update a relationship attribute, the workflow needs write access to the objects on both sides of the relationship.
“Invalid formula”
This error appears on the Formula block when one or more variables in the formula have no value. For example, if your formula sums four currency attributes and one is empty, the formula fails because empty is not treated as zero.
To fix this, set a fallback value on each variable in the formula.
In the Formula block, click the variable you want to update.
Toggle Fallback on.
Set the fallback value to
0.Repeat for every variable that could be empty when the workflow runs.
Once fallback values are in place, empty attributes are treated as zero and the formula calculates as expected.
“Please provide a List Entry, not a Record” or similar
This error appears when a block receives the wrong type of input. Some blocks expect a list entry and fail if they receive a record. Others expect a specific type of record and fail if they receive a list entry or a different kind of record. For example:
An Update list entry block requires a list entry and will fail if a record is provided.
An Enroll in sequence block requires a person record for the recipient and will fail if a list entry or a different kind of record is provided.
To fix a block that needs a list entry but received a record, add a Find list entries block before the failing block. Configure it with a condition where Parent record > is > and select the record from your previous block as the variable. Then use the output of the Find list entries block as the input for the block that requires a list entry.
You can verify which type a block received by clicking the failed block in the run viewer and checking its Inputs in the sidebar.
“The provided Record is from a different Object”
When a block such as Update record has both an object input and a record input, this error means the record provided belongs to a different object than the one selected. For example, this can happen if the block’s object is set to Companies but receives a person record. Update the object or record so they match.
“Request failed (invalid JSON)”
This error appears on the Send HTTP request block when the request body contains malformed JSON. Common causes include missing or extra commas, unclosed brackets, or incorrect quote characters. To identify the issue, copy the body content and paste it into a JSON validator such as JSONLint to pinpoint the exact error.
Related resources
Learn how to create a workflow from scratch.
Explore the workflows block library for a full list of available blocks.
Learn how to manage your workflows, including enabling, disabling, and organizing them.