Cancelation of planned outages

[HMJ]

How do you handle the situation in a change process.

• A "Planned Outage" has been generated and been communicated (on the portal and per notification/mail)
• the change requester asks to cancel the change, therefore the planned outage becomes obsolete

currently you can only delete the "Planned outage", thereby losing the track record that is existed, We currently notify the subscribers by changing the text of the outage to indicate that the outage is obsolet, before deleting, but both options are not really a fit for the process of communicating this change of the chang/outage properly. 

[Tanushree Maiti]

Hi @HMJ 

Why to delete the outage record?

When the change is cancelled, go to the related Outage record, set the state to "Cancelled," and add a note explaining justification.

Leave the original start/end times intact to show it was planned, but that it did not materialize. 

[Vishal Jaswal]

Hello @HMJ 

Outages under Change Request related list (relationship) comes from table: task_outage where outage is a reference field referencing to table: cmdb_ci_outage (this is where you actually create any outage).

There are two use-cases I can think of:

1. User-Case#1: Change Requests created before the planned outage being created - Table: task_outage where you need to create records / entries for all such Change Requests:

You can validate all such Change Requests by opening them and scrolling down to the Outages tab which will reflect this outage now.

You can achieve the above via background script / fix script too. Now, you can either automatically cancel all such affected change requests manually or achieve it via flow or business rule on table: task_outage by GlideRecord the task field value (Change Request sys_id) or can also automate by sending e-mail to the Change Requesters and/or approvers. 

2. User-Case#2: Not allowing any new Change Request to be created for the existing outage duration via onChange Client script or onSubmit client script.