Incident Management — Overview
Incident Management records and manages site events that must be reported: Incident, Accident, and Illness. Staff create reports, managers review/approve, reports are sent to customers, and customers view and acknowledge/sign when needed.
Quick Mental Model
An event happens in a class or at a site:
- Staff create a draft incident (from admin or the Onsite App on tablet/mobile) with date/time, site, course, severity, description, and actions taken.
- Staff add affected attendees and attendee-specific information.
- Staff submit; someone with full-control reviews, requests changes, or approves.
- After approval, the system can generate PDF report and send it to customer contacts.
- Customers open the portal to view the report, acknowledge, or sign confirmation.
- The full lifecycle is recorded in history, with notification history for audit.
Three Report Types
| Type | FormTypeId | When to use |
|---|---|---|
| Incident | 101 | General events: behaviour, missing attendee, headcount issue, safety, conflict, property... |
| Accident | 102 | Accidents / injuries that need to be recorded. |
| Illness | 103 | Health: medication, allergy, fever, vomiting, or other medical situations. |
Main "Objects"
| Name | One sentence |
|---|---|
| IncidentFormInstance | Root aggregate: a FormInstance with FormCategoryId = IncidentManagement. |
| Incident attendee | Affected attendee, with role, internal note, customer-visible note, body marker. |
| Attachment | Internal file or attendee-linked file, stored in Blob and SQL record. |
| Generated PDF | Report PDF generated by Reporting service, stored in Blob, can be attached to acknowledgement. |
| Acknowledgement | Record for a contact/customer who must be notified, acknowledge, or sign. |
| NotificationJob | Async job when submitting an incident or sending a report to customer. |
| Description template | Default Description template per type; settings (full-control) edit it, and it pre-fills on create/edit. |
| Internal Notes | Internal-only field below Action Taken; staff can see it, customers cannot. |
Who Uses This Domain?
| Role | Main work |
|---|---|
| Staff / creator | Create draft, update, add attendee/attachment, submit. |
| Manager / full-control | Review, request changes, approve, send to customer, close/reopen/cancel. |
| Customer contact | View sent incidents, download report, acknowledge or sign. |
| Support / operations | Inspect history, notification history, files/PDF, access permissions. |
Suggested Reading Order
- End-user view — what staff, managers, and customers do.
- Core concepts — status, permission, attendee, acknowledgement, PDF.
- Architecture & data — aggregate on FormInstance, SQL/Blob/Notification.
- Codebase flow — UI/API/service/worker/customer portal.
- Data & read/write tables — main tables, read dependencies/Blob/Reporting.
- Common cases — permissions, status, send-to-customer, acknowledgement.