--- title: "Findings & Actions Overview" slug: "findings-actions-overview" tags: ["v8.2"] updated: 2025-04-29T21:30:42Z published: 2025-04-29T21:30:42Z canonical: "docs.serenityops.com/findings-actions-overview" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.serenityops.com/llms.txt > Use this file to discover all available pages before exploring further. # Findings & Actions Overview In any robust EHS program, identifying issues is only half the battle—what matters just as much is tracking them, addressing them, and preventing them from recurring. That’s where Serenity’s **Findings and Actions** application comes in. But we get it: terms like *“finding”* and *“action”* can sometimes feel ambiguous. So let’s break them down—clearly and simply. --- ## What Is a Finding? A **Finding** in Serenity is a **task-based record used to capture and track an issue that needs attention**. Think of it as a flag—something that’s been identified as unsafe, ineffective, or out of alignment with your safety standards. ### Findings may include: - An **unsafe condition** (e.g., exposed wiring, blocked exits) - A **failed or inadequate control** (e.g., a malfunctioning safety system) - A **gap in safety procedures** (e.g., missing PPE protocol for a new process) - Any **non-conformance** observed during EHS activities ### Where Do Findings Come From? Findings can be created **anytime, by anyone**. But they’re also **generated organically through core EHS processes**, such as: - Incident reports - Investigations and root cause analysis - Risk assessments - Inspections and audits This seamless integration ensures that when something goes wrong—or is at risk of going wrong—it’s not just noticed, it’s **formally captured** for follow-up. --- ## What Is an Action? An **Action** is a **task created to resolve a specific issue**—often a response to a Finding, but not always. Where a Finding says, *“Here’s the problem,”* an Action says, *“Here’s how we fix it.”* ### Actions are: - **Individual work orders** - Assignable to users or groups - Trackable with due dates and completion status - Often linked to a specific Finding, but can also be standalone For example: If a Finding identifies an unguarded machine as a hazard, the related Action might be: *“Install machine guard on Line 2 press.”* --- ## Why Are Findings and Actions Both Tasks? In Serenity, both **Findings** and **Actions** function as **tasks**—which means: - Each can be **assigned to an individual or group** - Each can have **due dates**, **status tracking**, and **completion workflows** What’s important is that they serve **different roles** in the resolution process—often involving **different stakeholders**. For example: Let’s say a safety officer identifies an unguarded machine during an inspection. - A **Finding** is created to document the hazard. - That **Finding is assigned to the safety officer**, who is responsible for verifying that the issue is fully resolved. Then, an **Action** is created to fix the problem—*“Install machine guard on Line 2 press.”* - That **Action is assigned to the maintenance team**, who will physically complete the installation. Once the **maintenance team completes the Action**, they mark it as complete. However, the **Finding remains open** until the **safety officer reviews and confirms** that the hazard is truly resolved. This structure ensures that: - Work is assigned to the **right people** - Each task is **tracked independently** - Safety teams retain **final validation** before an issue is considered closed --- ## The Workflow: From Observation to Resolution Here’s how the process might unfold in the real world: 1. **An issue is identified** during an inspection—a damaged ladder is found in a high-traffic area. 2. A **Finding** is created to document the unsafe condition. This record is assigned to the **safety officer**, who is responsible for overseeing the resolution of the issue. 3. An **Action** is created to address the problem—*“Replace damaged ladder within 48 hours.”* This task is assigned to a member of the **facilities or maintenance team**. 4. The **maintenance team completes the Action** and marks it as done in the system. 5. The **safety officer reviews the fix**, confirms that the new ladder is safe and installed correctly, and then **closes the original Finding**. This two-step workflow ensures: - **Clear accountability** across roles - **Proper sequencing** between resolution work and final validation - A full, **auditable trail from issue identification to resolution** It’s this structured handoff—from spotting a hazard to confirming it's been addressed—that drives **effective follow-through and continuous safety improvement**. --- ## ✅ Best Practices - Use Findings to **capture issues consistently**, even if they seem minor - Link Actions to Findings when appropriate to **preserve context** - Assign tasks to specific individuals or teams to drive **accountability** - Set due dates and monitor progress using dashboards or reports - Close the loop—**verify that actions truly resolved the issue**