Incidents

Use the Incidents module to report workplace events, capture the details that matter for the incident type, assess severity, and manage investigation and close-out activity in one place.

This module is configured for more than injury reporting alone. The current setup supports incident outcomes such as community complaints, environmental events, equipment damage, injuries, near misses, production events, psychosocial events, security events, vehicle-related events, and violence or abuse.

Access to some sections and actions depends on role. In particular, there are some restrictions on the User after the initial incident is logged, with some sections only visible or editable by an Admin role.

What you can record

Depending on the incident type and where the record is in the workflow, an incident can include:

• the Reporting Person
• the Date Reported, Date Occurred, and optional Time Occurred
• the incident Location
• a short Brief Description
• one or more Classification (Outcomes) values
• whether the incident was Work Related
• whether a Third Party was involved
• detailed narrative in Details
• immediate controls, witnesses, and linked records
• actual and potential severity ratings
• regulator reporting details
• investigation dates, team members, event sequence, contributing factors, root causes, recommendations, and cost

What you must complete depends on the current status and your role.

When you first log an incident in Draft, the required fields are:

• Reporting Person
• Date Reported
• Date Occurred
• Brief Description
• Classification (Outcomes)
• Work Related
• Third Party Involved
• Details

Reporting Person defaults to the current user, and both Date Reported and Date Occurred default to today.

Some specialist sections also introduce their own required fields when they become visible in Draft. For example, Linked Injuries is required when the incident is classified as an injury, and the psychosocial and violence-and-abuse sections include their own mandatory questions.

If the incident is later moved into Open, additional follow-up sections become available, including Specifics and Define Incident. In that stage, the required severity/reportability fields are:

• Actual Incident Severity
• Potential/Worst Case Incident Category
• Externally Reportable?

Severity-dependent investigation sections may also appear later. Access to those sections is role-based, and for the standard User role they are view-only rather than editable.

Incident workflow

The live workflow currently uses these statuses:

• Draft: the initial incident logging stage
• Open: a follow-up stage used after an admin reopens the incident for more work
• Closed: the read-only end state for logged or completed incidents

The configured progression is:

1. Create the incident and start in Draft.
2. Complete the sections that are available in Draft and select Log Incident.
3. Log Incident moves the record directly to Closed.
4. If the record needs more work later, an admin can use Re-Open to move it into Open.
5. From Open, an admin can use Close Off and Archive to return it to Closed.

Important access notes:

• there is no normal save-in-draft button in this workflow; Log Incident is the draft-stage action
• Re-Open and Close Off and Archive are not available to the standard User role
• if you cannot change the record status yourself, an admin must handle the workflow transition

Creating an incident

To create a new incident:

1. Open the Incidents module.
2. Create a new record. It opens in Draft.
3. Confirm the reporting details such as Reporting Person, Date Reported, Date Occurred, and Location.
4. Enter a clear Brief Description and the main incident Details.
5. Select one or more Classification (Outcomes) values so the relevant specialist sections appear.
6. Complete any visible specialist sections that apply. For injury incidents, use Log New in Injury Reports to create the injury record from inside the incident workflow.
7. Add any attachments you want included with the initial report. For the standard User role, attachments are only editable while the incident is still in Draft.
8. Select Log Incident to submit the record. The incident will move to Closed.
9. If more follow-up information is needed later, an admin can Re-Open the incident. In Open, access depends on role. The standard User role can update specialist sections, Specifics, and Define Incident, but not the original Report section or the investigation-only sections.

Classification-driven sections

One of the key features of this incident form is that the record expands based on the selected incident outcomes.

Depending on the chosen Classification (Outcomes), the form can show extra sections such as:

• Third Party Details when Third Party Involved is set to Yes
• Complaint Details for community complaints
• Environmental Impact Details for environmental incidents
• Equipment Details for equipment-related incidents
• Injury Reports for injury events, with Linked Injuries and a Log New action that opens the internal Injuries form
• Vehicle Details for vehicle incidents
• Violence and Abuse for aggressive or abusive incidents
• Production, Near Miss, Security, and Psychosocial sections for those incident categories

This lets one incident module support a wide range of event types without forcing every record to show every question.

These specialist outcome sections are the main expandable parts of the initial incident log. If the record is later moved into Open, additional follow-up sections such as Specifics and Define Incident also become available. For the standard User role, the investigation-only sections still remain read-only.

Recording injury details

When Classification (Outcomes) includes Injury, the Injury Reports section becomes available and Linked Injuries becomes mandatory.

Use Log New to create an injury record from within the incident. The linked form sits inside the same incidents module, so injury details can be managed in context rather than through a separate external module.

The internal Injuries form captures information such as:

• Injured Person and optional Date of Birth
• Date of Injury and optional Time of Injury
• Injury Classification such as First Aid, Medical Treatment, Lost Time, or Fatality
• Nature of Injury, Mechanism of Injury, and Body Part Affected
• Brief Description of Injury
• Treatment Provided
• Injury Manager

In practice, this means you can report the main incident, create one or more linked injury records as needed, and keep the incident and injury information connected for investigation, follow-up, and reporting.

Access by status

Draft is the initial logging stage. This is where the incident is first created, the Report and Details sections are completed, and the visible outcome-driven sections are filled in as needed. Log Incident is the action that submits the record from this stage.

Open is the follow-up stage used after the incident has been reopened for more work. Additional sections such as Specifics, Define Incident, investigation areas, and associated records become available here.

Closed is the end state for submitted or completed incidents.

Access inside those statuses depends on role. Admins can edit the full record and handle the workflow transitions. The standard User role can submit from Draft, can read the full record once it exists, and can update selected sections in Open, but cannot reopen, close off, edit attachments after draft submission, edit the original Report section in Open, or complete the investigation-only sections.

Key fields

Reporting and summary

• Reporting Person: who is lodging the incident
• Date Reported: when the incident was reported
• Date Occurred: when the event happened
• Time Occurred: optional time of the event
• Location: where it happened
• Brief Description: the short summary used in lists and notifications
• Details: the main narrative of what occurred

Basic incident classification

• Classification (Outcomes): one or more incident outcome categories that control which specialist sections appear
• Work Related: whether the incident is work related
• Third Party Involved: whether an external person or organisation was involved

When Third Party Involved is set to Yes, the form can capture Third Party Name, address, telephone, and comments.

Severity and reportability

• Actual Incident Severity: the assessed severity of what actually happened
• Potential/Worst Case Incident Category: the potential or worst-case severity if the event had ended differently
• Externally Reportable?: whether the incident needs to be reported outside the organisation
• Body Reported To: who it was reported to
• Date Reported On: when that external report was made

These fields sit in Define Incident, which becomes available in Open. For the standard User role, that means they are not part of the initial Draft submission.

This setup helps separate the real outcome from the possible consequence, which is useful for learning from near misses and lower-consequence events that still had serious potential.

Investigation and cause analysis

The investigation area supports:

• Investigation Start Date
• Investigation Team
• Sequence of Events
• Witness Statements
• Immediate Contributing Factors
• Root Causes
• Recommendations
• Cost

In the current configuration, these investigation sections are shown conditionally based on the selected severity, so not every incident has to follow the same level of investigation.

These sections are intended for investigation follow-up rather than the initial incident log. For the standard User role, they can become visible on the record but are not editable.

Linked records

The form can connect an incident to other records through:

• Linked Injuries
• Associated Actions
• Associated Hazards

Vehicle-related incidents also have their own Vehicle Details section.

Access to linked-record areas depends on role. Linked Injuries can be managed while logging or updating the incident. Associated Actions and Associated Hazards sit in a read-only section for the standard User role.

For injuries, this is more than a simple cross-reference. Log New opens the internal Injuries form so the injury record can be created and linked from the same overall incident process.

Managing the investigation

Once the incident has been reported, the module can be used to:

• review the incident after submission, even when it is Closed
• update details and specialist sections as facts are confirmed
• complete Specifics and Define Incident during follow-up
• create or link injury records through Injury Reports
• document investigation notes, causes, recommendations, and associated records during follow-up

Exactly which of those actions you can perform depends on role. For the standard User role, investigation writing, associated action or hazard linking, attachment updates after submission, and workflow changes are handled elsewhere.

Notifications and lists

The current configuration includes notification templates for key events such as new incidents, reassignment-related changes, closing, and reopening. In practice, this means the module can be used to keep the right people informed as the incident progresses.

The incident list is configured to surface key information such as:

• Brief Description
• Date Occurred
• Date Reported
• Classification (Outcomes)

Additional fields such as severity ratings can also be made available in list views, which helps teams monitor incident patterns and review workload.

Common questions

• Why can't I just save the record and come back later? This workflow does not expose the normal save-in-draft action. The main draft-stage action is Log Incident.
• Why did my incident move to Closed as soon as I selected Log Incident? Because the current workflow sends Draft directly to Closed. The Open status is only used if an admin later reopens the record for more work.
• Why can't I see Specifics or Define Incident when I first create the record? Those sections belong to the Open follow-up stage, so they are not part of the initial Draft view.
• Why can't I change Reporting Person, Date Occurred, or the other Report fields later? If you are on the standard User role, the Report section is only editable while the incident is still in Draft.
• Why can't I add attachments after logging the incident? If you are on the standard User role, attachment editing is limited to Draft.
• Why can't I complete Investigation, Root Causes, or Recommendations? Those sections can appear on the record, especially for more serious incidents, but they are read-only for the standard User role.
• Why can't I see some sections? Sections appear only when their trigger conditions are met. For example, Third Party Details appears when Third Party Involved is Yes, the incident-type sections appear when the matching Classification (Outcomes) value is selected, and the investigation sections depend on severity.

Tips for better incident records

• Write the Brief Description so the incident is understandable in lists and emails without opening the record.
• Choose every relevant Classification (Outcomes) value so the correct specialist sections appear.
• Add any attachments before you select Log Incident. If you are on the standard User role, you cannot edit attachments afterward.
• If the incident is reopened into Open, use Actual Incident Severity and Potential/Worst Case Incident Category deliberately; they answer different questions.
• Complete external reporting details only when the incident is genuinely reportable and your role has access to Define Incident.
• Use Log New in Injury Reports where needed so linked injuries are created from the incident context with better traceability.
• If you need the status changed, the report header corrected, or investigation-only sections updated and your role cannot do that directly, ask an admin or other responsible person with that access.