Incident can transition directly from New to Closed without Close Code / Close Notes via form update

[DXCD]

Hi Community,

I am investigating an Incident that was updated directly from New (state 1) to Closed (state 7) without passing through Resolved (state 6).

The Incident was also closed without Close Code and Close Notes.

Based on the audit and transaction logs, the update originated from a Form transaction rather than REST. The transaction used the standard Update UI Action.

The current Data Policy makes Close Code and Close Notes mandatory only when the Incident state is Resolved (state 6), not when it is Closed (state 7).

I also checked the relevant Business Rules but could not identify any rule responsible for this direct state transition.

I tried to reproduce the behavior through both the standard Incident form and Service Portal, but I was unable to reproduce it.

My questions are:

Is it possible for an Incident to transition directly from New to Closed through a standard form update?

Is there any out-of-box validation that should normally prevent this transition?

If Closed (state 7) is submitted directly from the form, can the standard Update action save the record without Close Code and Close Notes?

What other configurations or logs should I check to determine how Closed (state 7) was submitted from the form?

Thank you.

[Mark Manders]

Not sure if I understand you correctly. Do you mean that the status field was set to 'closed' on the form, or was the 'close' ui action used? 
In either of those cases, you are allowing to move to closed. The system does not force the resolve status to be the only status that can be closed from.

And with your UI policy only stating that the closed fields are mandatory on resolved, then yes, they aren't mandatory on 'closed', so you can update without those fields being filled.

[BhavaniYamsani]

Hi @DXCD ,

A direct transition from New (1) to Closed (7) can occur if no applicable state-transition validation prevents it. The standard Update UI Action does not, by itself, enforce a mandatory sequence through In Progress and Resolved.

Regarding your questions:

1. Is a direct New → Closed transition possible through the standard form?
   Yes, if the applicable configuration does not prevent it. The Update action saves the submitted state; it does not inherently guarantee that intermediate states were visited.

2. Is there OOB validation to prevent this?
   Check the Data Policy Make close info mandatory when resolved or closed and the client script (BP) Close Mandatory on Close or Resolve. Verify that the Data Policy covers both Resolved (6) and Closed (7). State-transition restrictions are a separate concern.

3. Can Update save Closed without Close Code and Close Notes?
   If no applicable server-side validation requires those fields for state 7, the update may succeed. If an active Data Policy applies and enforces both fields, a normal form submission should not save the record with them empty.

4. What else should you check if the issue cannot be reproduced?

   • Review the Data Policy, client scripts, UI Policies and dictionary settings.

   • Inspect before-update Business Rules and flows that modify the state or closure fields.

   • Correlate sys_audit entries for state, incident_state, close_code and close_notes with the transaction timestamp.

   • Check system logs and available execution details for the same transaction.

Since you cannot reproduce the behavior, the available evidence does not yet establish whether this was caused by configuration, server-side logic or an exceptional transaction. The Form transaction and standard Update UI Action identify the request path, but not the exact cause.

Reference: ServiceNow Incident Management FAQs

If this answer helps, please mark it as helpful. Thank you!

Thankyou
Yamsani Bhavani
ServiceNow Developer
SecOps, GRC, Custom Applications, Now Assist