Investigate a safety incident

Investigating a safety incident is the work of establishing why it happened and deciding what to change so it does not happen again. In Bulk you do this with two structured root-cause methods — a fishbone analysis and a five-why analysis — and by turning your conclusions into corrective actions that become tracked tasks for your team.

A safety incident is a recorded event on your plant floor, such as an injury, a near miss, a spill, or equipment damage. Reporting the incident captures what happened; investigating it explains why, and drives the follow-up that closes the loop. Use investigation whenever an incident needs more than a note — when you need to find the underlying cause, capture lessons, and assign concrete corrective work.

Where investigation sits in the incident lifecycle

Investigation is the middle of a three-part flow. First you report the incident and submit it. Then you investigate: find the root cause and define corrective actions. Finally a reviewer approves and closes it once every corrective task is finished. This page covers the middle step.

Before you start

To open an incident and read its investigation you need the View safety permission (safety.view). To build or change the analysis and the corrective actions you need the Create incidents permission (safety.create_incident), because the analysis is authored as part of the incident report. In the default role set both permissions are held by the Super user, Entity admin, Manager, and Safety roles, so supervisors and safety-focused staff can investigate.

An incident must already exist to investigate. Investigation happens on a reported incident, so if there is nothing to work on yet, report the incident first. Everything you investigate belongs to the plant (also called an entity) you are signed in to — the incident, its analysis, and the tasks it generates all stay with that plant.

Build the analysis while you report

You author the root-cause analysis inside the incident report wizard, at its Root Cause and Actions steps. The full wizard walkthrough lives in Report a safety incident; this section explains the analytical content those steps capture.

On the Root Cause step you work through four parts:

Problem Statement — a plain description of the problem the incident revealed. This is the effect you are trying to explain.
Fishbone Analysis — a cause-and-effect diagram that sorts possible causes into six categories: People, Processes, Materials, Equipment, Measurements, and Environment. You add candidate causes under each category, click a cause to edit it, and mark the true underlying cause by starring it. You can keep up to five separate fishbone diagrams against one incident when a single event has more than one angle to explore.
Five Why Analysis — a chain of "why" questions where each answer becomes the next question, drilling from the surface symptom down to the underlying cause.
Root Cause — a short written summary of the cause your analysis identified.

On the Actions step you record what you will do about it:

Lessons Learned — the key takeaways from the incident.
Immediate Actions — actions taken right after the incident.
Preventive Measures — actions to stop it happening again.
System Changes — process or system updates the incident calls for.

When you submit the report, Bulk copies this analysis onto the new incident, moves the fishbone and five-why diagrams so they belong to the incident, and turns every corrective action into a task in your plant's Safety project. From that point on you review and track the investigation on the incident itself.

Review the investigation on the incident

Open the Safety area in the left navigation and choose Incidents to reach the Incident Reporting list. Select an incident's row to open its detail page. The header shows the incident title and its number (in the form INC-001), with a coloured status badge, and the body is organised into three tabs — Overview, Investigation, and Actions — beside a sidebar of Incident Status, Details, and a Timeline.

The Overview tab shows the Description and the Initial Problem Statement, the evidence attached to the incident, and the Approval Workflow card. The two tabs that matter for investigation are Investigation and Actions.

The Investigation tab

Select Investigation to see the root-cause analysis gathered in one place: the Fishbone Analysis diagram, the Five Why Analysis, the identified Root Cause, and the Lessons Learned. If a section was left blank when the incident was reported, it says so plainly — for example "No root cause has been recorded." — so you can tell at a glance whether the analysis is complete.

The Actions tab

Select Actions to see the corrective work, split into the same three groups you defined when reporting: Immediate Actions ("Actions taken immediately after the incident"), Preventive Measures ("Actions to prevent recurrence"), and System Changes ("Process or system updates required"). Each group lists the tasks Bulk created from your action items, and each task shows its name, its status, and who it is assigned to. A group with nothing in it reads "No actions recorded".

Drive the corrective actions to completion

The tasks on the Actions tab are the real output of the investigation: they turn your conclusions into tracked work. Each one is created in your plant's Safety project and starts with a To Do status. Your team works these tasks like any other — assigning an owner, setting a due date, and moving them to Done — from the Tasks area of Bulk.

Completing this work is also the gate to finishing the incident. Bulk lets a reviewer close an incident only after it has been Approved and every linked corrective task has reached a finished state (Done or Cancelled), with no action item left without a task. Until then, the Close Incident dialog lists the open and missing tasks that are blocking closure. The mechanics of approving and closing are covered in Approve a safety incident.

A thorough investigation makes closing straightforward

Because closing checks that every corrective task is finished, the quality of your Actions step directly shapes how the incident ends. Action items with clear descriptions become clear tasks; each one you complete moves the incident closer to being closable.

Example: Granite Peak Manufacturing

At Granite Peak Manufacturing's Leeds Fabrication Plant, an operator reports a near miss: a stack of steel blanks slid off a pallet near the press line. Safety lead Dana reports the incident and works the Root Cause step. Her Problem Statement reads "Unsecured blanks slid from a pallet in Bay 3." On the Fishbone Analysis she adds causes under Processes (no banding standard for part-finished pallets), People (new starter not briefed on stacking limits), and Environment (uneven floor near the press). She stars the Processes cause as the root cause. Her Five Why Analysis runs from "blanks slid" down to "there is no written rule for how high part-finished pallets may be stacked."

On the Actions step Dana records the Lessons Learned, then adds an Immediate Action ("re-band the affected pallets today"), a Preventive Measure ("brief all press-line staff on stacking limits"), and a System Change ("add a maximum stack height to the pallet-handling procedure"). She submits the report. Bulk creates the incident, moves her fishbone and five-why onto it, and creates three Safety tasks. Over the next week her team completes each task; once they are all Done, the incident is ready to be closed.

Expected result

After investigating, the incident carries a documented reason it happened — a fishbone diagram with a starred root cause, a five-why chain, a written root-cause summary, and captured lessons learned — and a set of corrective actions that exist as tracked Safety tasks. When every one of those tasks is finished, the incident can be approved and closed with a complete record of what was found and what was done.

Availability and limitations

This feature is generally available.

The analysis is authored during reporting. The problem statement, fishbone diagram, five-why chain, root cause, lessons learned, and corrective actions are entered on the report's Root Cause and Actions steps before you submit. On the incident's detail page the Investigation tab presents that analysis for review rather than for editing, and the Actions tab lists the tasks it generated.
Fishbone diagrams are limited per incident. You can keep up to five fishbone analyses against a single incident. Use additional diagrams only when one event genuinely has separate causal threads.
Corrective actions live as tasks. Each action item becomes a task in your plant's Safety project. You reassign, reschedule, complete, or cancel those tasks in the Tasks area, not on the incident; the incident reflects their current status.
Investigation is scoped to one plant. An incident and its analysis belong to the entity you are signed in to. If you cannot find an incident, confirm you are working in the plant that owns it.

Troubleshooting

The Investigation tab looks empty. The Root Cause step was skipped when the incident was reported, so no analysis was captured. Sections that were left blank show messages such as "No root cause has been recorded." or "No lessons learned have been captured yet."
The Actions tab shows "No actions recorded". No corrective action items were added on the report's Actions step for that group, so no tasks were generated. Action items are added while reporting; see Report a safety incident.
An incident will not close. Closing is blocked while any linked corrective task is still open, or while an action item has no task. Open the Actions tab, finish or cancel the outstanding tasks, then try to close again. See Approve a safety incident.

Report a safety incident — capture the incident and author its root-cause analysis and corrective actions in the report wizard.
Approve a safety incident — review, approve or return, and close an incident once its corrective tasks are finished.
Safety overview — the rest of the Safety area and how incidents fit alongside risk assessments and pre-use checks.

Investigate a safety incident

On this page