Skip to main content
New Idea

Confirmation to Promote a Major Incident

Related products:Freshservice
  • May 29, 2024
  • 3 replies
  • 88 views

mbutler
Top Contributor ⭐
Forum|alt.badge.img+10

I just recently had a Major Incident and had previously done some work and created workflows with Twilio around my Major Incidents. All of this worked flawlessly 😁.

However, I was just thinking that the “Promote to Major Incident” button is just a button. There is no confirmation that I’m aware of. Additionally, before an incident can be promoted to a major incident, I’d like to know which service and what level of outage we are dealing with, so I can send an appropriate message to the appropriate stakeholders.

It would be great if a few things could happen when the “Promote to Major Incident” button is clicked:

  • Verify a service is selected (if so desired by the admin)
  • Make sure Major incident type is selected (if so desired by the admin) - since this only exists in a Major incident - I’d like them to select one before the incident is created
  • Pop a confirmation box asking the user if they are sure they would like to promote it to a major incident (if so desired by the admin) - since this only exists in a Major incident - I’d like them to select one before the incident is created

In each of these, you may have industries where they just want to hit the button and it does what it needs to do, but I don’t feel like an extra half second to confirm that’s the action they want to take is inappropriate here.

It would be best if the message displayed to the user was customizable.

3 replies

Forum|alt.badge.img+2
  • May 30, 2024

Great to hear your Twilio workflows are working flawlessly! 😊 Regarding the "Promote to Major Incident" button, adding these features could enhance its functionality:

Verify Service Selection: Ensure a service is selected before promoting.
Ensure Major Incident Type: Confirm the Major Incident type is chosen before promotion.
Confirmation Box: A customizable confirmation box to verify the action and display relevant details about the service and outage level.
These steps can be optional for admins who prefer a streamlined process. This ensures accuracy and proper stakeholder communication. Like the certainty in Surah Al-Waqiah https://surah-al-waqiah.com/, these checks provide clarity and precision in handling major incidents.


mbutler
Top Contributor ⭐
Forum|alt.badge.img+10
  • Author
  • Top Contributor ⭐
  • May 30, 2024

Great to hear your Twilio workflows are working flawlessly! 😊 Regarding the "Promote to Major Incident" button, adding these features could enhance its functionality:

Verify Service Selection: Ensure a service is selected before promoting.
Ensure Major Incident Type: Confirm the Major Incident type is chosen before promotion.
Confirmation Box: A customizable confirmation box to verify the action and display relevant details about the service and outage level.
These steps can be optional for admins who prefer a streamlined process. This ensures accuracy and proper stakeholder communication. Like the certainty in Surah Al-Waqiah <LINK REMOVED> these checks provide clarity and precision in handling major incidents.

There needs to be a way to confirm these options.


DanielRuff
Top Contributor ⭐
Forum|alt.badge.img+9
  • Top Contributor ⭐
  • September 2, 2024

@mbutler Totally agree on your idea.

To ensure all required fields are completed, we mandate the creation of a new major incident rather than promoting an existing incident to a major incident. Since business rules do not apply to the buttons at the top, I revert the major incident back to a regular incident. The same applies to the “Close” button, where the option to remove the button via business rule is now available.

All tickets from a customer must be linked as child tickets/incidents under the major incident. This approach ensures a clean communication strategy.

Unfortunately, business rules do not apply to the UI of new major incidents; they are only applicable to “incidents.” Therefore, we use a checkbox that is only visible for major incidents. Once the agent toggles this checkbox, business rules are triggered to change the visibilities and fields.

Business rules should be capable of the following (for both change management and incident management):

  • Change visibilities for major incidents without a workaround
  • Make an asset mandatory
  • Make a service mandatory
  • Disable adding/removing assets/services

Disabling assets is possible within change management via business rule. We could enforce making assets mandatory via API and readers. You can only change the status if there is at least one asset associated with the change. So why is it not possible for services?

Back to your idea about a popup dialog:

A “popup” feature could be beneficial across the entire product. This would require the agent to fill in certain fields before proceeding, as some fields are hard to see in the attributes. It could also serve as a confirmation prompt to ensure the agent is certain about their action or to explain a feature. For example:

  • Agent sets the status to pending
  • A popup appears asking when they want a reminder for that ticket (pending until)
  • The ticket reopens on the specified date

We could address this via a scheduled workflow, assuming a maximum period of 4 weeks. However, the custom field for that date is hidden among many other fields. Ideally, the agent would be prompted to set a date by which they want to review the ticket (unless customer replies before the date).