Opportunity Changed Trigger: Event-Based Operators to Reduce Misfires

January 28, 2026•3 min read

We added event-based operators to the Opportunity Changed trigger to stop workflows from firing for every change. These operators let us target specific events—like when a value changes, when it changes to a specific value, or when a checkbox is added or removed. That makes our automations more precise and reduces misfires.

What changed

The update expands the available operators for both standard and custom fields. The goal is simple: let workflows trigger only when the right event happens. Below is a quick summary of the main updates.

Standard fields

Assigned To and In Pipeline now support has changed, has changed to, and equals.
Status now supports has changed and has changed to.
Lost Reason adds the equals operator (in addition to its existing operators).

Custom fields

Checkbox supports added, equals, and removed. This helps when we want a workflow to run only when an option is selected or deselected.
Radio select, dropdown, and date fields now offer has changed, has changed to, and equals.

How event-based operators work

There are three common patterns we use to build precise triggers:

has changed — triggers when the field value changes in any way. Useful for generic change monitoring.
has changed to — triggers only when a field changes to a specific value. Use this to detect transitions, for example when Status changes to Closed.
equals — evaluates the current value. This is best when the trigger should run only if the opportunity is already at a specific value, regardless of how it got there.

Checkboxes add two more event-specific operators:

added — triggers when an option is selected.
removed — triggers when an option is deselected.

Practical examples

Run a handoff sequence only when Assigned To has changed to a specific rep. This avoids retriggering when other fields update.
Send a final notice when Status has changed to Closed Lost, and use Lost Reason equals to customize messaging.
Start a follow-up only when a Checkbox is added, for instance when a lead opts into a premium offer.
Use has changed for broad monitoring, such as keeping an audit log when critical fields change.

Best practices

Prefer has changed to when the workflow depends on a specific transition.
Use equals for state checks where the current value matters, not how it changed.
Combine operators with other filters to narrow triggers further (for example, only when opportunity value is above a threshold).
Test triggers in a sandbox or with a small sample to confirm they fire only when expected.

FAQ

What are event-based operators and why use them?

Event-based operators let us specify the exact kind of change that should trigger a workflow. They reduce misfires by focusing triggers on specific events, like a field changing to a value or a checkbox being added.

Which standard fields were updated?

Assigned To and In Pipeline now support has changed, has changed to, and equals. Status supports has changed and has changed to. Lost Reason adds equals.

How do checkbox operators work?

Checkboxes support added, equals, and removed. Use added to trigger when an option is selected and removed to trigger when it is deselected. Equals checks whether the checkbox is currently selected.

Will these changes stop all misfires?

They significantly reduce misfires by letting us target specific events, but we should still combine operators with other filters and test workflows to ensure the desired behavior.

Any tips for testing triggers?

Create a test opportunity, make controlled changes, and observe whether the workflow fires. Start with small, isolated tests, then expand to real data once behavior is confirmed.

These operators give us clearer triggers and smoother automations. They help ensure workflows run only for the right contacts and events, resulting in better results and less manual cleanup.

This article was created from the video Opportunity Changed Trigger: Event-Based Operators to Reduce Misfires