Confirmation on "Demote Major Incident" Availability for Resolved Incidents

[kathj]

Hi Community,

I would like to seek confirmation regarding the behavior of the "Demote Major Incident" functionality.

I am currently investigating an incident where the caller reported that the "Demote Major Incident" button is unavailable when the incident is already in the Resolved state. During my investigation, I reviewed the out-of-the-box MajorIncidentTriggerRulesSNC Script Include and found that it appears to be working as designed. Based on the OOB logic, the "Demote Major Incident" button is automatically hidden when the incident state is Resolved, Closed, or Canceled.

However, the caller insists that approximately two months ago they were able to demote a Major Incident even when the incident was already in the Resolved state. Based on my findings, this does not appear to be valid behavior.

Can anyone confirm whether the expected OOB behavior is that Major Incidents can only be demoted while they are in an active state, and that the demotion option is intentionally hidden once the incident reaches Resolved, Closed, or Canceled.

Additionally, I am looking for any documentation, release notes, or evidence that can help confirm that this behavior is not related to an instance upgrade (specifically the Australia release) and has been the intended OOB behavior.

Any confirmation or supporting references would be greatly appreciated as they will help me close the ticket with confidence.

Thank you in advance.

[Tanushree Maiti]

Hi  @kathj 

Refer these links:

KB0821456 Resolved Major Incident State 

Demote a major incident 

https://www.servicenow.com/community/developer-forum/demote-reject-major-incident-ui-action-when-sta...

[kathj]

Hi @Tanushree Maiti , thanks for this but it doesn't resolve my question.

[Kieran Anson]

Hi there,

You're correct, this behaviour hasn't changed recently. If you need to validate it, you could spin up a PDI on Zurich. Although instances aren't readily available right now....

One possibility is that the user had the incident open prior to the state change. The state was then changed, either by another user or in another browser window, and that reflected on the record via live updates. UI actions don't re-evaluate until the page is reloaded. So it could appear an incident is resolved and the incorrect UI actions display.