Changing incident type for effective incident resolution - Genetec Mission Control™ 2.13.4.0

Genetec Mission Control™ Administrator Guide 2.13.4.0

series
Genetec Mission Control™ 2.13.4.0
revised_modified
2020-10-27

You can use the Change incident type activity to trigger another incident as part of your incident resolution process.

Incident resolution by triggering other incidents

Some incidents require a coordinated effort between multiple teams or multiple organizations with different incident management procedures. For example, a traffic accident might involve 911 personnel, emergency care, police departments, and so on. On a smaller scale, an Access denied event might trigger other incidents for incident resolution.

Depending on the incident, you can use Collaborative incidents or the Change incident type activity to resolve your incident.

The Change incident type activity preserves the history of the incident including the incident ID but continues incident resolution by ending the current automation workflow and executing the automation workflow of the newly triggered incident. As a rule, the Change incident type must be the last activity in the incident automation workflow.

When incidents trigger other incidents as part of incident resolution, Genetec Mission Control™

maintains a record of all these linked incidents. You can access this information by clicking the Related incidents section in the Incidents tab, in the Incident monitoring task.

The operator can also link incidents manually in Security Desk by clicking the Add () button in the Linked incidents section and entering the Incident ID.

Example scenario: Access denied incident

Consider an incident configuration for Access denied incidents. The automation workflow design includes four activity branches that perform different incident resolution activities based on the cause of the Access denied event.
Anti-passback violation
The first activity branch is for Access denied incidents triggered by anti-passback violations. This branch includes a Trigger incident activity that triggers another incident to resolve the incident.
Access rule
The second activity branch is for Access denied incidents triggered by access rule violations. This branch includes incident resolution activities.
Expired credential
The third activity branch is for Access denied incidents triggered by expired credentials. This branch includes incident resolution activities.
Other
The fourth activity branch is for Access denied incidents triggered by any other Access denied event. This branch includes a Trigger incident activity that triggers another incident to investigate Access denied the incident.

Instead of the Trigger incident activity in the Access denied: Other branch, you can use the Change incident type activity. This changes the triggered incident into another incident with a different set of properties.

The system then stops this automation workflow, and in this example, triggers the Access Denied - Investigate incident and continues with the automation workflow of the Access Denied - Investigate incident to investigate the cause of the Access denied incident.

However, the Change incident type activity preserves the history of the parent Access denied incident, aggregated entities, events and incident ID.

This activity along with all actions performed so far are recorded in the Latest activity log:

In this example, there are no linked incidents in the Related incidents page, because it is counted as one incident that has changed type instead of as two incidents.

Change incident type activity explained

In this example, one normal incident is changed into another. Here, any non-collaborative incident is considered a normal incident.

However, if multiple teams are required to resolve the incident, you can use the Change incident type activity to change a normal incident to a collaborative incident.

Depending on your requirement, you can either trigger the collaborative incident or trigger a sub-incident of a collaborative incident using the Change incident type activity. It is unnecessary for the parent collaborative incident to be triggered if not required.

The incident that triggers the sub-incident will be added as another sub-incident to the parent collaborative incident.

The only requirement is that the collaborative incident must have at least one valid sub-incident. If not, the system will cancel the Change incident type activity as an invalid operation.

While a normal incident can be changed into a collaborative incident, a collaborative incident cannot be converted into a normal incident using the Change incident type activity.