Skip to main content
Most Attio workflow failures fall into a handful of patterns you can diagnose by symptom and fix in the run viewer. Each section names one thing you can see go wrong. That might be a workflow that never fired, an empty variable, or an error about the wrong input type. Each section then lists the causes worth checking first and ends with the concrete repair. Work top to bottom. The order roughly matches how often each failure shows up in a production workspace. Before you change any block, open the failed run. The run viewer shows each block’s actual inputs and outputs. That means you diagnose from real run data instead of reasoning in the abstract. Most of the fixes that follow start in that viewer.

​
Workflow never fires

A workflow that never fires is almost always a trigger mismatch, not a broken block. A trigger is the event that starts the workflow. Check these causes in order.
  • The trigger type is wrong for the event. A Record updated trigger never sees a value set during record creation. For that, use Record created.
  • The change happened on a list entry, but Record updated watches object attributes. A list entry is a record’s membership in a list. Changes to list membership or to list-entry attributes fire List entry updated, not the record trigger.
  • The workflow is still a draft. Nothing triggers until you click Publish.
  • The trigger is scoped to the wrong object, list, or attribute. The event you expect falls outside that scope, so it never runs.
Fix. Compare the event you expect against choosing the right trigger. Then confirm the workflow is published and its trigger scope matches the object, list, or attribute that actually changed.

​
Variable output is empty

An empty variable means the output you referenced never produced a value on the path this run took. A variable is a piece of data passed from one block to another. The reference points at a real block. The block just had nothing to hand it.
  • The output you selected sits on a branch the run never executed. A Switch or If block sent the run down a different path, so the upstream block never produced its output.
  • A Find records or Find list entries block returned zero matches, so its record output is empty.
  • A workflow with more than one trigger is missing a data-source fallback. The input reads from a trigger that did not fire this run, so it comes back empty.
  • An AI or agent output was expected to save itself. It does not. AI blocks return text into the run and nowhere else.
Fix. Open the run viewer and inspect the upstream block’s outputs on the executed path. Where an input can read from more than one trigger, add data sources in order with a static fallback. The variables & data passing page shows how. To persist an AI result, follow the AI block with Update record and map the output into an attribute.

​
”Please provide a List Entry, not a Record”

This error means a block expecting a list entry received the parent record instead. A record and its list entry are different things in the engine. Typed inputs reject the wrong one outright.
1

Confirm which type the block expects

Open the failing block in the run viewer and read its input. A block such as Update list entry requires a list entry, while Update record requires a record.
2

Look up the matching entry

Add a Find list entries block. Configure it to locate the entry for the triggering record on the target list. For example, find the Inbound list entry for the company acme.com.
3

Pass the entry output downstream

Wire the entry output from Find list entries into the block that raised the error, replacing the record reference. The error clears once the input type matches.
The reverse error is “Please provide a Record, not a List Entry”. It has the mirror fix: reach the record through the list entry’s parent. Both directions are covered in records vs list entries.

​
Sequence enrollment fails

Enroll in sequence is strict about who it enrolls and who sends. So an enrollment failure is usually a typed-input or permission problem, not a sequence bug.
  • The recipient is not a person record. The block takes a person record, not a company and not a list entry. Reach the person through a relationship attribute on the triggering record.
  • The sender does not have delegated sending enabled, so Attio cannot send on their behalf.
  • The workflow lacks sequence access under its permissions.
Fix. Validate the recipient type and the sender configuration before the Enroll in sequence block. Confirm that the person, for example Priya Sharma, resolves to a person record. Confirm that the sender has delegated sending, and that the workflow has sequence access.
Re-enrolling someone who is already in the sequence does not fail the run, so a duplicate enrollment is never the cause. Look at the recipient type, the sender, and access first.

​
Formula validation fails

A Formula block fails outright when an input is missing or the wrong type. It returns no partial result, so the whole block errors.
  • A numeric variable is empty, so the formula has nothing to compute. This is the most common cause.
  • An input carried unexpected text where a number was expected.
  • The formula uses an invalid operator or function.
Fix. Set a fallback of 0 on every numeric variable that could be empty. This is the documented fix, and it belongs on essentially every formula you write. Then test the block against real run data in the run viewer. The test confirms that each input resolves to the type the formula expects.

​
Credit usage is higher than expected

Unexpected credit spend comes from volume, not from a single pricey block. The usual culprit is a workflow firing more often than you thought. The other is a paid block running on records it should have filtered out first.
  • An unscoped trigger fires on far more events than intended. Scope the trigger to a specific attribute where possible.
  • A Loop wraps a 1-credit write, so the per-run cost scales with the number of items.
  • An AI block runs before the Filter, so it processes records that a filter would have excluded.
  • Two duplicate workflows are both active, doubling the writes.
Fix. Open the run viewer to inspect run volume, the executed path, and per-run credits. Then cross-check against billing usage. Move any Filter ahead of paid blocks, set a Loop Limit while testing, and disable duplicate workflows. For the per-block costs and plan allowances behind these numbers, see credits & pricing explained.
Per-workflow credit caps were removed in the new engine, so there is no cap to set as a safety net. Control spend by scoping triggers, filtering before paid blocks, and limiting loops instead.

​
See also

Source: Attio Help Center: Troubleshooting workflows. Last reviewed against the Attio Help Center, June 2026.