Won. That makes it the safer choice for most stage and status rules. Point it at an object to watch an object attribute, or at a list to watch a list attribute.
Inputs
Outputs
Reference the new value in a later block as
{{ steps.attribute_value_changed.new_value }}, and the previous value as {{ steps.attribute_value_changed.previous_value }}.
Behavior
The trigger evaluates one attribute on one object or list. It fires when that attribute moves from empty to a value, from one value to another, or from a value back to empty. It also fires when the value is set during record or list-entry creation. So a deal created directly asWon triggers it. That is the case that Record updated and List entry updated miss.
Each firing gives you both the new value and the previous value. With both, you can spot a real change in state, not just any edit to the attribute. On the first-ever set of an attribute, the previous value is empty. Re-saving the same value does not count as a change, so the trigger does not fire when the value is unchanged.
A workflow that writes back to the same attribute will re-fire this trigger, because a workflow is an actor like any other. To avoid a trigger loop, scope the trigger to an attribute your workflows never write. You can also guard the run with an early Filter on the actor. See infinite loops and safety.
Gotchas
- Watches the object, misses the list. A pipeline
stageis usually a list attribute, not an object attribute. A trigger pointed at the object never fires on stage moves. Point the trigger at the list instead, and read records vs list entries to tell the two apart. - Fires on every set, not only the transition you want. Without a value check, the trigger runs each time the attribute changes to anything, including back-and-forth edits. Add an early Filter comparing the new value to the target, such as
New value is Won. - Re-fires the same stage as a fresh win. A re-save of
WonoverWondoes not fire. But a move fromWontoNegotiationand back toWondoes. Filter for a true transition withNew value is WonandPrevious value is not Won. Otherwise a re-entered deal sends a duplicate alert. - Loops when a workflow writes the attribute. If any workflow updates the watched attribute, this trigger fires again and can chain into a loop. Filter out the workflow actor, or watch an attribute that workflows never set.
Examples
Alerting on a closed-won deal
Point the trigger at theSales pipeline list and watch the Stage attribute. Then filter for the true transition into Won before alerting.
When a rep drags
Acme renewal from Negotiation to Won, the workflow posts to #wins and fires a celebration. A deal re-saved as Won sends nothing, because the previous value was already Won.
Catching a status set at creation
Point the trigger at theCompanies object and watch the Lifecycle attribute. This way, companies created already marked Customer are caught, not just those edited later.
Lifecycle set to Customer fires the trigger and creates the kickoff task. Record updated would have stayed silent here, because the value was set at creation.