Workflow Template

Incident Investigation Workflow

Captures a reported workplace incident, guides an investigator through evidence and root-cause analysis, classifies severity, routes minor incidents to corrective action closure and serious incidents through management review and regulatory reporting, then notifies the reporter and action owners on closure.

Organisations with statutory health and safety obligations require a defensible, consistent process for capturing, investigating, and closing out workplace incidents, with clear evidence trails to satisfy internal governance and external regulators. This workflow guides safety, HSE, and operational teams from initial incident capture through investigator assignment, root-cause analysis, and severity classification, routing minor incidents to corrective action closure and serious incidents through management review and regulatory reporting. Reporters, investigators, safety reviewers, and action owners are each engaged at defined stages, with status tracking and notifications supporting accountability throughout the incident lifecycle.

Business Outcomes

Supports faster assignment and initiation of incident investigations
Helps standardise root-cause analysis and severity classification across sites
Reduces the risk of unresolved corrective actions falling through the cracks
Improves traceability of regulatory reporting decisions for audit purposes
Streamlines closure communication to reporters and action owners

Workflow Steps

Steps

1
Create incident recordcreate record
Registers the reported incident as a record.
2
Set status to Reportedupdate record
Marks the incident as newly reported.
3
Assign investigatorassign user
Assigns a safety investigator to the incident.
4
Set status to Under Investigationupdate record
Updates status as the investigation begins.
5
Investigate incidentcreate task
Investigator gathers evidence and witness information, reconstructs the sequence of events, and identifies causes.
6
Persist investigation findingsupdate record
Writes the investigator's findings and severity classification to the record.
7
Route on severity classification
Routes minor incidents to corrective action closure and serious incidents to management review.
severity_classification: "Minor"→Assign corrective actions
severity_classification: "Serious"→Set status to Pending Management Review
Default→Assign corrective actions
8
Assign corrective actionscreate task
Assigns corrective actions to an action owner for a minor incident.
9
Safety reviewer sign-offrequest approvalrequires approval
Safety reviewer approves closure of the minor incident.
10
Route minor closure outcome
Branches on the safety reviewer's approval decision.
approval_status: "approved"→Close minor incident
approval_status: "rejected"→Return for further corrective action
Default→End
11
Return for further corrective actionrestart from step
Restarts the corrective action task because the reviewer did not approve closure.
12
Close minor incidentupdate record
Marks the minor incident as closed.
13
Notify reporter of closuresend email
Sends closure notification email to the reporter.
14
Notify action owner of closuresend email
Notifies the corrective action owner that the incident is closed.
15
Set status to Pending Management Reviewupdate record
Updates status as the serious incident moves to management review.
16
Management reviewrequest approvalrequires approval
Management reviews the serious incident investigation findings.
17
Route management review outcome
Branches on management's approval decision.
approval_status: "approved"→Determine regulatory reporting requirement
approval_status: "rejected"→Return for further investigation
Default→End
18
Return for further investigationrestart from step
Restarts the investigation because management rejected the findings.
19
Determine regulatory reporting requirementcreate task
Safety team confirms whether the serious incident requires regulatory reporting and completes it if so.
20
Persist regulatory reporting statusupdate record
Writes the regulatory reporting outcome to the record.
21
Close serious incidentupdate record
Marks the serious incident as closed after management review and any regulatory reporting.
22
Notify reporter of closuresend email
Sends closure notification email to the reporter.
23
Notify action owner of closuresend email
Notifies relevant action owners that the serious incident investigation is closed.

Fields

Incident Description*
Date of Incident*
Location*
People Involved*
Immediate Controls Taken
Reporter Name*
+7 more fields

Forms

Workplace Incident Report

8 fields

Data Views

All Incidents

incident_ref, incident_status, severity_record, incident_location +1 more

Dashboard Widgets

Incident Status SummaryIncidents by SeverityIncident Investigation Pipeline

Recommended integrations

Setup the following integrations to extend workflow capability.

Send email in the workflow
AWS SES

incident investigationworkplace incident investigationsafety investigationaccident investigationroot cause

Similar Workflows

workplace incident reporting root cause analysis corrective action

Similar Categories

health safety quality management

FAQs

How is this workflow audited for compliance purposes?

Every step, from incident creation through investigation, severity classification, sign-off, and closure, is timestamped and retained within assess.one, creating a running record of who did what and when. This history can be reviewed to demonstrate adherence to internal safety governance requirements or to respond to regulatory or insurer inquiries. Status changes such as 'Under Investigation' or 'Pending Management Review' are logged as part of the audit trail rather than tracked manually.

Who has access to incident records and investigation findings?

Access is configured within assess.one by role, so reporters, investigators, safety reviewers, and management approvers typically only see the information relevant to their stage of the process. Sensitive investigation findings and root-cause analysis can be restricted to designated investigator and reviewer roles. Administrators can adjust these permissions at any time as organisational structures or reporting lines change.

How does this integrate with existing safety or notification systems?

Notification steps such as alerting the reporter and action owner on closure are configured directly inside assess.one using built-in email or Slack integrations, without requiring separate development work. Teams can connect these notifications to existing communication channels used by their safety or operations function. Additional integrations can be added or adjusted as the workflow evolves.

Who typically needs access to this workflow?

Frontline employees or supervisors who report incidents, assigned investigators, safety reviewers who sign off on minor incident closures, and management reviewers involved in serious incident escalation all typically require access. Action owners responsible for corrective actions also need visibility into tasks assigned to them. Access can be scoped narrowly so each participant only interacts with the steps relevant to their role.

What happens when an incident is routed based on severity?

Once investigation findings are persisted, the workflow routes the incident according to its severity classification. Minor incidents proceed to corrective action assignment and safety reviewer sign-off before closure, while serious incidents move into management review and a regulatory reporting determination. This branching logic is configured within the platform and can be adjusted to reflect an organisation's own severity thresholds.

What happens if a corrective action or management review is not satisfactory?

The workflow includes explicit return paths: minor closure outcomes can be sent back for further corrective action, and management review outcomes can be returned for further investigation. This means an incident is not closed prematurely if evidence or remediation is judged insufficient. These decision points are designed to support a more rigorous, defensible closure process rather than a single pass-through approval.

Can the workflow be customised to reflect our organisation's incident classification or approval hierarchy?

Yes, steps, roles, severity criteria, notification recipients, and approval logic can all be customised directly within assess.one to match an organisation's specific safety policies and reporting hierarchy. Additional review stages or fields for capturing evidence can be added without needing external development support. Changes take effect immediately once published.

How is regulatory reporting handled within the workflow?

For incidents classified as serious, the workflow includes a dedicated step to determine whether regulatory reporting is required, followed by a step to persist the reporting status as part of the incident record. This creates a clear, retrievable record of the reporting decision that can support compliance reviews or regulator requests. The determination step can be configured to align with the specific regulatory thresholds applicable to the organisation's jurisdiction or industry.

How long does it take to implement this workflow?

The workflow is ready to use as a template, so it can be reviewed, adjusted to reflect internal roles and severity definitions, and published in minutes rather than through a lengthy implementation project. Once published, teams can begin logging and investigating incidents immediately. Further refinements to steps or notifications can be made at any time without disrupting incidents already in progress.

Ready to use this workflow?

Create a free account and customise this workflow for your business.