Major incidents should not be allowed to cancel by end user

ramesham
Tera Contributor

Major incidents (P1,P2) should not be allowed to be "Cancelled" which are in Accepted (Promoted) state.

How do we define this workflow.

1 ACCEPTED SOLUTION

Jan Prochazka
Tera Guru

Hi Ramesham,

 

First, let's be clear what we are talking about

 

When talking about Major Incidents, I assume, we are talking about Major incident management (servicenow.com) capabilities provided by the plugin Activate Incident Management - Major Incident Management (servicenow.com)

 

There are two independent State fields:

  • one for Incident state [incident.state]
  • and the other for Major incident state [incident.major_incident_state]

These two states have different purposes, and there is a big difference between canceling the entire Incident (setting the state of the Incident to Canceled) and cancelling the Major Incident (setting the Major incident state to "Canceled").

 

While canceling the Incident is a kind of terminal state of the given Incident (saying it won't be resolved), canceling the Major Incident  only means that the Incident is no more Major and can be resolved via a standard Incident Management process. Cancelling the Major Incident is called Demoting and you shouldn't block this possibility as this is a wanted part of the Major Incident process: Demote a major incident (servicenow.com)

 

And now to answering your question

 

Based on what was said above, I assume, what you are after is disabling an ability to turn the cancel the given Incident (set its state to Canceled) when it was already promoted to Major Incident (what means the Major incident state = Accepted.

 

The simplest solution for this is a "reactive one" - create a before update business rule preventing to update Incident state to “Canceled” when Major incident state is "Accepted". Within this business rule you can also provide back to the user an explanation why this operation is not allowed and was aborted.

 

Like this:

 

JanProchazka_5-1682622049403.png

 

JanProchazka_4-1682621475729.png

 

I hope this helps.

 

Regards,

Jan

View solution in original post

2 REPLIES 2

Jan Prochazka
Tera Guru

Hi Ramesham,

 

First, let's be clear what we are talking about

 

When talking about Major Incidents, I assume, we are talking about Major incident management (servicenow.com) capabilities provided by the plugin Activate Incident Management - Major Incident Management (servicenow.com)

 

There are two independent State fields:

  • one for Incident state [incident.state]
  • and the other for Major incident state [incident.major_incident_state]

These two states have different purposes, and there is a big difference between canceling the entire Incident (setting the state of the Incident to Canceled) and cancelling the Major Incident (setting the Major incident state to "Canceled").

 

While canceling the Incident is a kind of terminal state of the given Incident (saying it won't be resolved), canceling the Major Incident  only means that the Incident is no more Major and can be resolved via a standard Incident Management process. Cancelling the Major Incident is called Demoting and you shouldn't block this possibility as this is a wanted part of the Major Incident process: Demote a major incident (servicenow.com)

 

And now to answering your question

 

Based on what was said above, I assume, what you are after is disabling an ability to turn the cancel the given Incident (set its state to Canceled) when it was already promoted to Major Incident (what means the Major incident state = Accepted.

 

The simplest solution for this is a "reactive one" - create a before update business rule preventing to update Incident state to “Canceled” when Major incident state is "Accepted". Within this business rule you can also provide back to the user an explanation why this operation is not allowed and was aborted.

 

Like this:

 

JanProchazka_5-1682622049403.png

 

JanProchazka_4-1682621475729.png

 

I hope this helps.

 

Regards,

Jan

ramesham
Tera Contributor

This is working as expected in the backend but we also want to restrict this in the front end user portal as well.