Inputs
Outputs
Reference the updated record’s identifier in a later block as
{{ steps.record_updated.record_id }}. Reference a scoped attribute’s change as {{ steps.record_updated.new_value }} and {{ steps.record_updated.previous_value }}.
Behavior
The trigger fires once per update event on a record of the selected object. An update is any change to an object attribute after the record already exists. So many things qualify. An edit by a teammate, an enrichment write (an automatic fill-in of a field), an APIPATCH, or another workflow all count as an update.
New and previous values exist only when you scope the trigger to a single attribute. An unscoped trigger reports that the record changed. But it cannot tell you which attribute changed, or what the value was before. So transition filters such as New value is X and Previous value is not X work only on a scoped trigger.
The trigger does not fire for two documented cases. First, it ignores values written during record creation. A record created with a value was never “updated”, so a deal created as Won never crosses this trigger. Second, it ignores changes to list attributes. A list attribute is a field that lives on a list, such as a pipeline stage. Moving a record’s stage on a pipeline list is a list-entry change, not an object-attribute change. See Records vs list entries for the distinction.
Any actor can update a record, including the workflows you build. This means the trigger can fire on its own writes, which can cause a loop. To keep a run from re-firing itself, filter on the actor. You can also scope the trigger to an attribute your workflows never touch. See Infinite loops and safety for the guard pattern.
Gotchas
- Unscoped is a run-volume firehose. Without an attribute, the trigger fires once per touched record on every enrichment pass, every sync, and every bulk edit. That floods run history and burns credits on whatever paid blocks follow. Scope the trigger to the one attribute the workflow cares about. Then add a Filter right after it as a second line of defense.
- The trigger re-fires its own writes. If this workflow, or any workflow, updates the same object, that write is itself an update. So it starts the trigger again, which can loop. Guard it with a Filter set to
Updated by → Type → is not → Workflow. You can also scope the trigger to an attribute your workflows never write. - New and previous values are missing on an unscoped trigger. Transition logic such as
New value is X and Previous value is not XreadsNew valueandPrevious value. Those exist only on a scoped trigger. Scope the trigger to the attribute you are testing before you build the transition filter. - Creation-time values never reach this trigger. A record imported or created with the field already set does not count as an update. So a “field became X” rule misses every record born with X. Trigger on Attribute value changed instead. It fires at creation and on later edits.
- Stage moves on a list never reach this trigger. Pipeline stage usually lives as a list attribute. Changing it is a list-entry change, not an object-attribute change. Use List entry updated for pipeline movement.
Examples
Routing an ownership change to the new owner
This workflow runs a handover when a company’s account owner changes. It ignores its own writes and other workflows’ writes.
Say
Priya Sharma reassigns the acme.com company to Jane Okafor. The trigger fires, and the filter confirms a human made the change. A handover task then lands on Jane’s queue, due in three days.
Acting only on a true status transition
This workflow alerts a channel when a company’s status first becomesAt risk, and ignores re-saves of the same status.
Status on At risk fails the previous_value is_not At risk test. So the alert fires only on the genuine move into At risk, not on every save.