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 workflow and executing the workflow of the newly triggered incident. As a rule, the Change incident type must be the last activity in the incident 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
- 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.
- 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 workflow, and in this example, triggers the Access Denied - Investigate incident and continues with the 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.