Incident Management — End-User View

This page looks at the domain by user actions, before going into code.

Staff Create Incident

Staff open Incident Management (from admin or Onsite App) and click New Incident:

1. Choose type: Incident / Accident / Illness.
2. Enter date/time, site, course if any, severity, title, description, action taken.
3. Description auto-prefills from the template for the selected type (editable text, no visible token); manual edits are not overwritten when other fields change.
4. Choose an incident subtype that matches the selected type.
5. Configure whether customer notification, acknowledgement, or signature is required.
6. Add affected attendee, attendee-specific description, customer-visible note, and body marker if needed.
7. Save draft to continue editing, or submit when ready.

The form labels customer-visible vs internal-only for each field:

• Customer-visible: Title, Description, Action Taken; attendee Role, Customer Visible Notes; body marker Body Part, Injury Type, Note, Diagram.
• Internal-only: Created By, Internal Notes (directly under Action Taken), attendee Description — never exposed to customer.

Opened from Onsite App: entry "Incident" only appears when the user has permission; list is limited by the site provided by the app (one site hides selector, multiple sites limit choices); viewing/downloading/uploading attachments works directly inside the tablet/mobile webview.

Manager Review and Approve

Users with full-control process incidents after they are submitted:

Status	Common actions
Submitted	Start Review, Request Changes, Approve, Cancel
Under Review	Request Changes, Approve, Cancel
Changes Requested	Creator edits and submits again
Approved	Generate PDF, Send To Customer, Close

When edits are needed, the manager uses Request Changes with a comment. The comment stays in history so the creator knows what to fix.

Send Report to Customer

After an incident is Approved, the manager can:

1. Generate PDF report: the popup asks for visibility first. Uncheck Internal Use Only ⇒ customer-visible report, one PDF per attendee. Check Internal Use Only ⇒ choose either one combined report (default) or one PDF per attendee.
2. Send To Customer: select customer contacts to send to.
3. Choose delivery channels based on configuration/request.
4. Checkbox Include PDF report is checked by default — attach the latest generated document to the acknowledgement; uncheck to send notification without document.
5. Send the report to customer.

The system creates FormAcknowledgement for contacts:

Contact	Acknowledgement role
Primary contact	Responsible for acknowledging or signing if the incident requires it.
Non-primary contact	Usually notification-only; receives the message but is not responsible for submitting acknowledgement.

Customer View and Confirm

Customer opens the Incidents page in the customer portal:

1. Sees incident list for the current account.
2. Opens detail using their acknowledgement id.
3. Views summary, related attendee, customer-visible notes, generated PDF if attached.
4. Clicks acknowledge or signs confirmation if the incident requires signature.

Settings: Description Template (Full-Control)

Settings icon on the Incident Management page only appears for full-control. Clicking it opens the template manager:

• One editable Description template for each type (Incident, Accident, Illness), with the list of allowed placeholders.
• Type with no saved template ⇒ shows built-in default; saving writes the template to blob and sets PrefillBlobName for the active version of that type, scoped by Business Unit.

Progress Feedback on Refresh

After each successful action (add/edit/delete attendee, upload/delete attachment, generate PDF, workflow action), the UI keeps loading feedback until the refreshed detail has been applied — no manual reload needed, and no old state shown as if it were new. Opening detail for the first time can still use a full-page spinner. If a mutation succeeds but refresh fails, the system reports "succeeded but could not refresh the latest data" and stops the spinner.

What Should Support/Operations Check?

• Incident detail: current status, attendee, acknowledgement, attachment, generated PDF.
• History timeline: who created/edited/submitted/approved/sent/acknowledged/closed.
• Notification history: which jobs were created, which event type, recipient, and delivery method.
• Permissions: create-only users only see their own incidents; full-control is required for review/governance actions.

Next: Core concepts.