Incident State ‘Changes To Resolved’ fails, but ‘Is Resolved’ works

VianyNidamanuri — Mon, 09 Nov 2026 15:59:28 GMT

I am investigating a strange issue with the "changes to" condition operator on the Incident table.

The following conditions do not evaluate as true:

Send Resolved IT Only Comms changes to Yes

and

Incident State changes to Resolved

I tested these independently and together.

Neither condition triggers a Notification or an After Update Business Rule.

Replacing the same conditions with static value checks works immediately:

Send Resolved IT Only Comms is Yes

and

Incident State is Resolved.

The Notification and Business Rule both execute successfully.

Additional testing performed

I initially observed this behavior in a Notification.

To rule out Notification evaluation timing, I created an After Update Business Rule using the same conditions.

The result was identical:

Send Resolved IT Only Comms changes to Yes

→ Does not trigger

Incident State changes to Resolved

→ Does not trigger

Send Resolved IT Only Comms is Yes

→ Triggers

Incident State is Resolved

→ Triggers

I also tested the notification as an Event-based notification and moved the conditions into the Business Rule. The result remained the same. Any condition using "changes to" does not evaluate as expected, while the equivalent "is" condition works.

What makes this confusing

The incident is definitely being updated and the final values are present on the record:

Send Resolved IT Only Comms = Yes

Incident State = Resolved

Since the values are correctly updated and visible on the record, this does not appear to be a field value issue. The problem seems to be specifically related to how the "changes to" operator is being evaluated.

Additional context

Table: Incident [incident]
Tested in both Notifications and After Update Business Rules
Record is updated through the standard resolution process
No recent configuration changes were made to this logic
Similar logic reportedly worked correctly around 6 months ago
Issue is consistently reproducible

Questions

Has anyone seen "changes to" conditions stop evaluating correctly for Incident State or custom Yes/No fields?
Are there any known platform changes, Incident lifecycle behaviors, or transaction timing issues that could cause "changes to" to evaluate false while the updated values are correctly stored on the record?
Is there a recommended way to inspect how ServiceNow is evaluating the "changes to" operator during Notification and Business Rule execution?

#ServiceNow #BusinessRule #Notification #IncidentManagement #ServiceNowAdmin #ServiceNowDeveloper #ITSM #Incident #PlatformSupport #CommunityHelp

question Incident State ‘Changes To Resolved’ fails, but ‘Is Resolved’ works in Community Central forum

Incident State ‘Changes To Resolved’ fails, but ‘Is Resolved’ works

Additional testing performed

What makes this confusing

Additional context

Questions