List entry updated

The List entry updated trigger fires when a list attribute changes on an entry in a specific list.

The List entry updated trigger fires when a list attribute changes on an entry in a specific list. A list attribute is a field that belongs to a list, not to the underlying record. A pipeline stage is almost always a list attribute. So this is the trigger you reach for when a deal moves from one stage to the next.

This trigger does not fire for object attributes, which are fields on the record itself. It also does not fire for values that are set at the moment an entry is created.

Category	Triggers
Credit cost	Free. Triggers consume no credits
Engine	New Workflows engine (June 2026+)
Plan availability	All plans
Limits	None documented.

Inputs

Input	Type	Required	Default	Notes
List	List	Yes	None	The list to monitor.
Attribute	List attribute	No	None	If set, the trigger fires only when this list attribute updates. If unset, the trigger fires on any list-attribute change on any entry in the list.

Outputs

Output	Type	Example	Notes
List entry	List entry	Acme renewal on Sales pipeline	The full entry that was updated.
Actor	Actor	Priya Sharma	Who performed the change.
Timestamp	Datetime	2026-06-11T14:32:00Z	When the change happened.
New value	Attribute value	Proposal	Present only when an attribute is selected on the trigger.
Previous value	Attribute value	Demo booked	Present only when an attribute is selected on the trigger.

Reference the new stage downstream as {{ steps.trigger.new_value }} and the prior stage as {{ steps.trigger.previous_value }}.

Behavior

The trigger fires once per matching change on a single entry. When you scope it to one attribute, only changes to that attribute fire it. The run then carries both the new value and the previous value.

When you leave the attribute unset, every list-attribute change on every entry fires it. That includes priority tweaks, owner reassignments, and any other list attribute. In this case the new and previous values are not available.

The new and previous values exist only when an attribute is selected. Filters that test a real transition, such as New value is X and Previous value is not X, depend on these two outputs. So leaving the attribute unset removes the values your downstream conditions need.

A re-save of the same stage still counts as an update. Suppose you set an entry’s stage to Proposal when it is already Proposal. The run shows the new value and the previous value as identical, which is why transition logic should test both.

Gotchas

• Unset attribute floods the workflow. With no attribute selected, every priority tweak, owner change, and note edit on the list fires the trigger. Scope the trigger to the one list attribute you care about. That is usually the stage attribute.
• Same-stage re-saves re-fire downstream actions. Saving the current stage again sends a run through with the new value equal to the previous value. That re-runs your alerts and tasks. Filter for a real transition with New value is X and Previous value is not X. Duplicate Slack alerts are usually how you discover this.
• Creation-time values are not updates. An entry added to the list with its stage already set never fires this trigger, because no update occurred. Catch creation-time values with Attribute value changed pointed at the list.
• Object attributes never fire this trigger. Annual recurring revenue changing on the company record does not fire this trigger, because that is an object attribute, not a list attribute. Use Record updated for object attributes. Read Records vs list entries to see why the two are separate.

Examples

Routing a deal by its new stage

Scope the trigger to the stage attribute, then branch on the new value with a single Switch. One workflow then owns every stage, instead of five single-stage workflows.

Field	Value
List	Sales pipeline
Attribute	Stage

A Switch on {{ steps.trigger.new_value }} sends each stage to its own action. Demo booked goes to a prep task via Create task. Proposal goes to a #deals alert. Won goes to a Celebration. Lost goes to Exit from sequence. One run history holds every path, so debugging a misrouted deal happens in a single place.

Alerting only on a real stage transition

Filter out same-stage re-saves so a deal moving into Won notifies the team exactly once.

{
  "trigger": {
    "list": "Sales pipeline",
    "attribute": "Stage"
  },
  "filter": {
    "all": [
      { "field": "new_value", "operator": "is", "value": "Won" },
      { "field": "previous_value", "operator": "is_not", "value": "Won" }
    ]
  }
}

A rep who re-saves the deal while it is already Won produces a run whose new value and previous value both read Won. The second filter condition then fails, so no duplicate alert fires.

Source

Attio Workflows block library.

Last reviewed against the Attio Help Center, June 2026.

See also

• Attribute value changed
• Record updated
• Records vs list entries
• Slack deal alerts on stage change
• Attio Workflows block library