- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-26-2023 11:53 PM
Major incidents (P1,P2) should not be allowed to be "Cancelled" which are in Accepted (Promoted) state.
How do we define this workflow.
Solved! Go to Solution.
- Labels:
-
Architect
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-27-2023 11:14 AM - edited 04-27-2023 12:44 PM
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:
I hope this helps.
Regards,
Jan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-27-2023 11:14 AM - edited 04-27-2023 12:44 PM
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:
I hope this helps.
Regards,
Jan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-03-2023 06:59 AM
This is working as expected in the backend but we also want to restrict this in the front end user portal as well.