Dev Blog: Creating InformaCast Incident Management

Tags: 
InformaCast-incident-management-dev-blog

Each month, we have a member from the Singlewire Software development team present a deep-dive, behind-the-scenes look at a recent project. This month, one of our software engineers, Ben, walks us through the recent addition of incident management capabilities to our InformaCast software.

The Customer Need

InformaCast Fusion excels in getting notifications out quickly. However, customers also needed the ability to manage ongoing incidents after an initial notification was sent.

Suppose you have an IT outage and want to notify all your employees. InformaCast gets this information to each employee as quickly as possible across several available channels. However, this is rarely the end of the situation. Updates are needed to keep people informed about the current status, what attempts have been made to fix the problem and the eventual resolution. Trying to find each of these notifications can be time-consuming and difficult during a crisis event. The ability to group each of these notifications into a single "Incident" would be much more convenient, helping save precious time when seconds matter.

To solve this problem, Singlewire released InformaCast Incident Management to all InformaCast Mobile and Fusion customers in July 2021. This feature allows administrators to configure Incident plans, trigger incidents with the appropriate plan, and manage the incident until it concludes. When an event has concluded, customers are able to review the incident in a generated report.

Scoping the Project

With the problem identified, the Singlewire team gathered requirements for the incident management feature. In order to give administrators the necessary tools to manage an incident, four key components were established:

1. Incident Plans

Incident plans allow administrators to configure quick-access notifications and incident resources they want available to their team during an incident.

Quick-access notifications are any message templates or scenarios applicable to a given incident. For example, if the office experiences an IT outage, the "Notification to Staff" scenario would be useful to have in the quick-access list.

Furthermore, incident resources are the files or hyperlinks associated with an incident. Continuing with the IT outage example, an organization's IT status page could serve as a helpful link.

2. Triggering an Incident

Once an incident plan is configured, it may be attached to a scenario or message template to start an incident when a message or scenario is activated. Users may also trigger an incident manually by specifying the incident plan in the user interface.

3. Managing the Ongoing Incident

During the incident, administrators have the ability to send their quick-access notifications, view any configured resources, and end the incident. However, incidents do not always follow the steps outlined in an organization’s plan. Therefore, users are also able to send a custom notification and modify any incident resources for the duration of the incident.

4. Reviewing the Completed Incident

The incident report becomes available once a user ends the incident. This report provides information about each sent notification as well as any confirmation response information that came from recipients during the incident. Additionally, completed incidents remain in a read-only state so that administrators may go back and review the event at any time.

Building the Solution

Configuring Incident Plans

To facilitate CRUD (create, read, update, delete) operations for incident plans, we implemented a new /incident-plans API resource with attributes including a name, description, and the IDs of any message templates or scenarios available for quick-access. An example response for an IT outage incident plan may look like this:

incident-management-dev-code-1

We also added the /incident-plans/{incidentPlanId}/resources subresource to support attaching useful hyperlinks and files on an incident. Each incident plan resource is represented in the following format:

incident-management-dev-code-2

With the above JSON, we have all the information we need to instantiate an incident.

The Incident

InformaCast Fusion administrators can trigger an incident by specifying the incidentPlanId field on a message template or a scenario. If they wish to start an incident without sending a notification, this can be done by issuing a POST request to the /incidents endpoint with the incidentPlanId in the payload.

Ongoing incidents can be ended at any time, but will expire automatically after 30 days. Until then, administrators may send quick-access notifications, view their incident notifications, and add or delete any incident resources for their team in the Fusion Admin Console.

Completing an incident is as simple as submitting a POST request the /incidents/{incidentId}/activities subresource with the following payload:

incident-management-dev-code-3

The Incident Report

Upon completing the incident, administrators gain access to the incident report. The incident report displays all confirmation response and notification information captured throughout the incident.

In addition, the incident goes into a read-only state similar to notifications. This ensures the incident and incident report can be referenced in the future.

Feature Complete

InformaCast Incident Management is available to all InformaCast Fusion and InformaCast Mobile customers. This feature targeted a well-known issue for incident teams and now provides a much better experience managing incidents from start to finish.

 

 

InformaCast Online Demo