Incident Panel
The Incident Panel is the ACCELERO screen that works as an alarm center: relevant events generated by the system (automatically or by I/O automations) are consolidated into a list that the operator monitors in real time and handles until resolution.
Navigation path: Incidents
The Incident Panel is an advanced module (ocorrencias). The screen and the automations that generate incidents are only available when the module is enabled in the license. See Licensing.
Concept
Unlike a manual note record, the panel is fed by the system itself. Whenever an event considered relevant happens — for example, a controller goes offline or a duress password is used — ACCELERO creates an incident that needs to be triaged by the operator.
The screen shows only the open incidents and updates itself every 15 seconds, ensuring the operator always sees the most recent situation without having to reload the page.
Each incident keeps who acknowledged it, who handled it (with the mandatory handling note) and who normalized it, in addition to the creation and completion dates — preserving the complete history of the event.
The listing
Each row represents an open incident. The columns shown are:
| Column | Description |
|---|---|
| ID | Unique identifier of the incident |
| Creation | Date and time the incident was generated |
| Type | Type of the incident (e.g. Controller offline, Duress) |
| Data | Specific details of the event that originated the incident |
| Priority | Criticality of the type: Low, Medium or High |
| Actions | Acknowledge, Handle and Normalize buttons |
The list is ordered by creation date (most recent first) and shows only incidents not yet fully closed. An incident only leaves the screen, on the next update, when all three markers are set: acknowledged, handled and normalized. Normalizing without acknowledging and handling does not remove it from the list.
Visual indication by state
The rows receive color highlighting according to the point in the life cycle they are at, allowing you to quickly identify what requires attention:
| Row color | State |
|---|---|
| Red | Not acknowledged and not normalized (requires attention) |
| Green | Normalized but not yet acknowledged (e.g. a gateway or controller that came back online and normalized the incident on its own) |
| Orange | Acknowledged, not yet handled or normalized |
| Blue | Handled, not yet normalized |
The panel always brings the most relevant information directly in the row (type, priority and event data), precisely to allow a quick decision and action by the operator.
Incident life cycle
Every incident goes through up to three milestones, triggered by the buttons in the Actions column:
Created ──▶ Acknowledged ──▶ Handled ──▶ Normalized (closed)
(acknowledge) (handle) (normalize)
1. Acknowledge
Signals that an operator became aware of the incident. The system asks for a simple confirmation ("Confirm ACKNOWLEDGMENT of the incident?"), with no text field, and stores which operator did the acknowledgment.
2. Handle
Records the handling of the incident. When you click Handle, the system opens a dialog with a text field for the descriptive note of what was done. The title of this dialog is Acknowledgment message (the screen reuses that label), but it is the one that records the handling.
It is not possible to handle an incident without filling in the handling history data: with the field empty, the system rejects the action with the message "It is mandatory to inform historical data!" and the incident stays as it was. This note is recorded in the incident's history.
The act of handling also marks the incident as acknowledged (if it was not already) and records the operator responsible for the closure.
3. Normalize
Indicates that the situation was normalized/resolved. The system records the completion date and the operator who closed it. The incident only leaves the list when it has also been acknowledged and handled; normalized without those steps, it stays on the screen (in green).
Internally, each incident keeps three independent markers — acknowledged, handled and normalized. Some incident types advance part of these markers automatically; for example, a controller that comes back online can normalize the corresponding incident on its own.
Incident types
Each incident belongs to an Incident type, which defines its description and its priority (a numeric value converted into Low, Medium or High). The types are reused both by the automatic generation and by the I/O automations.
The system reserves types for the events it generates automatically:
| Incident type | When it occurs | Note |
|---|---|---|
| Expired event | When a visit/event is not closed by the expected end date | — |
| Environment occupancy | When the occupancy configured for an environment is exceeded | — |
| Controller offline | When there is a communication failure with an access controller | — |
| Duress | When the system detects a duress event (duress password/finger) | Critical event |
| Synapsis — Redzone | When unauthorized presence is detected in a Redzone-type region | Requires Synapsis module |
| Synapsis — Alarm/panic | When the Synapsis module panic button is triggered | Requires Synapsis module |
| Synapsis — Dwell time | When the dwell time allowed in a region is exceeded | Requires Synapsis module |
| Elevator failure | When an early elevator call fails | Requires elevator module |
| Gateway offline | When there is a communication failure with a system gateway | — |
| Login with incorrect password | When an operator's login is rejected due to an incorrect password | — |
Some types are only generated when the corresponding module is licensed and configured (Synapsis, elevators, etc.).
How incidents are generated
Automatically, by system events
The types listed above are created by ACCELERO itself when the corresponding event happens. The creation is published in real time (via MQTT), and the screen reflects the new incident on the next update.
By I/O automations
The Generate Incident action of the I/O Automations module allows you to turn any I/O input into a manageable incident. In the action configuration you define:
- Incident type — which type will be assigned to the generated incident;
- Title — descriptive text that appears in the incident's Data.
The I/O action avoids duplicating incidents: while there is already an open incident of the same type for that I/O handler, a new trigger normalizes the existing incident instead of creating another. Thus, an input that oscillates generates an incident when activated and closes it when normalized.
Notifications
Operators can subscribe to incident types to be notified when they change state. The configuration is in the operator's record, in the Notifications tab:
- Subscribed types — which incident types the operator follows;
- Delivery method — None or Email.
When an incident of a subscribed type is acknowledged, handled or normalized, the subscribed operators receive an email notification containing the incident data and the action taken.
See Operators — Notifications for the configuration.
Permissions
The actions of acknowledging, handling and normalizing require edit permission over the incidents (ocoManage). Make sure the operators responsible for triage have this permission in their access profile.
Best practices
- Keep the panel open during operation — since it updates itself every 15 seconds, it works well as a continuous monitoring panel.
- Acknowledge quickly, handle with a record — acknowledging signals awareness; handling requires a clear note of what was done, which becomes history.
- Prioritize by criticality — start with High priority incidents and critical types (duress, alarm/panic).
- Only normalize after confirming the solution: normalization records the closure; for the incident to leave the list, it must also be acknowledged and handled.
- Configure notifications for the right people — subscribe the relevant types so that managers and security teams are notified.
Next Steps
- I/O Automations — generate incidents from I/O inputs
- Operators — Notifications — configure who is notified
- Logs and Monitoring — understand the complete log system
- Synapsis — configure the Synapsis module for Redzone and panic