Fire Incident Documentation Release Notes: November 2025
New Features
Implement Unit Actions Behavior for Aiding Apparatus in NERIS
What - NERIS now properly handles Actions Taken for Aiding Apparatus, ensuring that deleting apparatus with incomplete action data no longer triggers invalid validation errors in the Operations section. The system includes automatic data cleanup logic that removes residual references when apparatus are deleted, and refined validation checks that only display legitimate errors for missing data rather than phantom errors from deleted apparatus records. This improvement enhances data integrity and ensures incident reports can be completed and authorized without unnecessary validation blocks.
Why - This enhancement was implemented to resolve validation issues that prevented users from completing and authorizing incident reports, improving user experience and ensuring validation errors only appear for legitimate missing data rather than deleted apparatus references.
How - No manual configuration is required to utilize this improvement:
Add and document Actions Taken for Aiding Apparatus in Operations/Actions as you normally would
If you need to delete an apparatus that has incomplete Action Taken data, the system will automatically clean related references from the incident report
Validation errors will only display for genuine missing or incomplete data, not for deleted apparatus
You can now finalize and authorize incident reports without encountering false validation errors from incomplete or removed apparatus records
Note: This behavior applies to both NERIS and NFIRS client environments
Use Case - A fire captain is completing a NERIS report for a mutual aid incident where three engines from neighboring departments assisted. While documenting the Actions Taken in the Operations section, they realize that one of the aiding apparatus was incorrectly added to the incident and needs to be removed before completing the action documentation for that unit. The captain deletes the incorrect apparatus entry from the report. Previously, this deletion would have left residual data references that triggered validation errors in the Operations section, blocking report authorization even though the apparatus was no longer part of the incident. With this enhancement, the system automatically cleans up the related action references when the apparatus is deleted, and the captain can complete and authorize the incident report without encountering phantom validation errors, ensuring accurate documentation of only the apparatus that actually responded to the incident.
CAD Designation Restrictions with NERIS Update
What - Validation and synchronization for CAD Designations has been introduced for station and unit data integration with NERIS via API, ensuring consistent and compliant data exchange between systems. For NERIS-enabled clients, the Associate Dispatch Unit field is now mandatory in the Apparatus Catalog, and the CAD Designation field is required when creating or editing apparatus records. The NERIS readiness checklist validates that CAD Designation is not empty and meets NERIS regular expression requirements. Apparatus records with invalid or missing CAD Designations are rejected by NERIS and logged in the Export Log for correction and reprocessing, while the CAD Designation field remains optional for NFIRS-only clients.
Why - This enhancement was implemented to ensure data compliance with NERIS requirements, prevent apparatus registration failures, and maintain consistent data quality when exchanging station and unit information between First Due and NERIS systems.
How - To ensure apparatus records meet NERIS CAD Designation requirements:
Navigate to Apparatus Catalog
When creating or editing apparatus records, ensure both:
Run the NERIS readiness checklist to validate CAD Designation compliance before submitting data
If apparatus records are rejected, review the NERIS Export Log to identify failed records
Correct any invalid or missing CAD Designations in the flagged apparatus records
Resend the corrected apparatus information to NERIS
Note: CAD Designation validation only applies to NERIS-enabled clients; NFIRS-only clients are not required to complete this field
Note: A fallback value is used when a valid CAD Designation is not available to prevent data transmission failures
Use Case - A fire department is preparing to transition from NFIRS to NERIS reporting and needs to register all their apparatus with the state system. The fleet manager reviews their apparatus catalog and notices that Engine 3 has "Associate Dispatch Unit" populated as "E3" but the CAD Designation field is empty. When they run the NERIS readiness checklist, the system flags Engine 3 as having an invalid CAD Designation. The fleet manager opens the apparatus record, enters the proper CAD Designation "ENG03" that matches their dispatch system's format and meets NERIS regular expression requirements, and saves the record. After correction, they re-run the readiness checklist and Engine 3 now passes validation. When the apparatus data is transmitted to NERIS, all units are successfully registered. If they had proceeded without correcting the CAD Designation, Engine 3 would have been rejected by NERIS and appeared in the Export Log, requiring manual correction and resubmission before the unit could be used in NERIS incident reporting.
Enhancements
Improved Inactivity Timer Recognition in NERIS & NFIRS Reports
What - The inactivity timer functionality in NERIS and NFIRS reports has been enhanced to accurately recognize all active user interactions, including typing, scrolling, searching, and clicking within slide outs and narrative boxes. The system now continuously monitors these interaction types and properly resets the inactivity timer when any activity is detected, ensuring the inactivity pop-up only appears after genuine periods of inactivity rather than interrupting users who are actively working on reports. Autosave functionality now detects changes in narrative sections (Apparatus, People Involved/EMS, Department, and Impediments), preventing inappropriate inactivity warnings during active documentation.
Why - This enhancement was implemented to resolve issues where the inactivity pop-up was incorrectly appearing while users were actively completing incident narratives, causing frustrating interruptions and potential data loss concerns during critical documentation tasks.
How - No configuration changes are required to benefit from this improvement:
Continue working in NERIS or NFIRS reports as normal, including typing in narrative fields, scrolling through forms, searching within pop-ups, or clicking on elements
Any of these interactions will automatically reset your inactivity timer, keeping your session active
If the inactivity pop-up does appear after genuine inactivity (based on your configured timeout period), you have two options:
Note: Narrative changes in Apparatus, People Involved/EMS, Department, and Impediments sections are automatically detected by the autosave function, preventing inactivity warnings while you're actively documenting
Note: Filling in apparatus narratives from the pre-populated list also counts as detected activity
Use Case - A paramedic is completing a complex EMS narrative in a NERIS report, documenting patient care and transport details for a cardiac arrest call. They spend several minutes typing detailed observations, occasionally scrolling up to review earlier sections, and searching through medication lists in a slideout panel. Previously, the inactivity pop-up would interrupt them mid-documentation, forcing them to click "Stay" and potentially disrupting their documentation flow. With this enhancement, all their typing, scrolling, and searching activities are recognized as active interaction, the inactivity timer continuously resets, and they can complete their comprehensive narrative without interruption. The inactivity pop-up will only appear if they genuinely step away from their computer for the configured timeout period, at which point they can choose to stay and continue or save and exit.
NERIS ZIP Code Validation in Readiness Checklist
What - The Readiness Checklist now includes enhanced validation to ensure all fire station addresses contain a valid ZIP code before allowing NERIS data submission. When a station address is missing or has an invalid ZIP code, the system displays an "Incorrect Station Address" error message, preventing users from proceeding until the address is corrected to include all required components (street number and name, city, state, and ZIP code). This validation uses the same logic applied during NERIS submission, ensuring consistency between the readiness check and actual data transmission requirements.
Why - This enhancement was implemented to prevent submission errors and reduce workflow disruptions caused by incomplete station addresses that previously passed the readiness checklist but failed during NERIS data transmission, ensuring data quality and alignment between validation checkpoints.
How - To ensure your station addresses pass NERIS readiness validation:
Navigate to the Readiness Checklist page
Review any stations displaying the "Incorrect Station Address" error message
Update the flagged station address to include all required components in the format: # and address, City, State, ZIP Code (example: 54 Miramar Blvd, Miramar, FL 33025)
Verify that the ZIP code is present and valid
Re-run the readiness checklist to confirm the station now passes validation
Note: Addresses selected from autocomplete must include a ZIP code to pass validation
Note: The same validation logic applies to both the readiness checklist and NERIS submission, preventing discrepancies between the two processes
Use Case - A fire department administrator is preparing to submit their monthly NERIS report and runs the Readiness Checklist to ensure all stations are configured correctly. The checklist displays an "Incorrect Station Address" error for Station 3, which has the address "Pasadena Blvd, Pasadena, TX, USA" without a ZIP code—an incomplete address that was previously accepted by the checklist but would have caused a submission failure. The administrator updates the address to "1250 Pasadena Blvd, Pasadena, TX 77506" with the complete ZIP code, re-runs the checklist, and confirms that Station 3 now passes validation. When they proceed to submit the NERIS data, the submission completes successfully without any address-related errors, saving time and eliminating the need to troubleshoot failed submissions.
NERIS Add 'None' as Option to Water Supply List
What - A new "None" option has been added to the Water Supply dropdown in the Incident Information form, allowing fire department officers to accurately document incidents where no water supply was used. This option persists across all incident statuses (Incomplete, Pending Authorization, and Authorized), can be used as a condition for triggering workflows, and is recognized as a valid value for required field compliance. The addition aligns First Due with the water supply values available in NERIS Swagger, ensuring complete and accurate incident documentation.
Why - This enhancement was implemented to provide fire departments with the ability to accurately document incidents that did not require or utilize a water supply, filling a documentation gap and ensuring compliance with NERIS reporting standards.
How - To use the new "None" water supply option:
Navigate to Incident Information within your NERIS incident report
Locate the Water Supply dropdown field
Select "None" from the dropdown list when documenting incidents where no water supply was used
Save your incident—the selected value will persist across all status changes
Note: If you have workflows configured based on Water Supply conditions, "None" can be used as a trigger criterion
Note: Incidents created before this update will retain their original water supply values, but "None" will become available if you edit the Water Supply field
Note: "None" is recognized as a valid value for required field validation
Use Case - A fire engine responds to a vehicle fire on a highway where the crew uses only portable extinguishers and foam from their apparatus to suppress the fire. No hydrants, tankers, or other water supply sources were utilized during the incident. The officer completing the NERIS report can now select "None" from the Water Supply dropdown, accurately documenting that no external water supply was used for this incident. Additionally, if the department has configured a workflow to automatically flag incidents with no water supply for training review or statistical tracking, selecting "None" will trigger that workflow, ensuring proper documentation and follow-up for incidents handled without traditional water supply resources.
Add Command Established Time/Date to NFIRS Notification Table
What - A new "Command Established Time/Date" field has been added to the NFIRS Notification Table, capturing command establishment information from incident reports. This field is automatically populated with values entered in either Dispatch > Response > Command Established (Time) or Operations > Command and Safety > Initial Command Established > Date/Time sections. The field is accessible through the API for integration with external systems and is available in both NFIRS and NERIS notifications, ensuring consistent command timeline documentation across all reporting platforms.
Why - This enhancement was implemented to maintain data consistency between incident reports and NFIRS/NERIS notifications, ensuring that critical command establishment timeline information is preserved throughout the reporting workflow and accessible for state reporting and external system integration.
How - No manual configuration is required to utilize this field:
Record the command establishment time during incident documentation in either:
Dispatch > Response > Command Established (Time), or
Operations > Command and Safety > Initial Command Established > Date/Time
The Command Established Time/Date will automatically populate in the NFIRS Notification Table
The field is accessible through the API for external reporting and integration needs
Note: This field is available for both NFIRS and NERIS notifications
Use Case - A battalion chief arrives at a working structure fire and establishes command at 14:23. The dispatcher or incident commander enters this time in the Dispatch > Response > Command Established field during the incident documentation. When the incident data is transmitted to the state NFIRS system, the Command Established Time/Date of 14:23 is automatically included in the NFIRS notification, ensuring the state receives complete timeline information about when incident command was formally established. If the department uses integrated reporting software that pulls data via API, that external system can also access the command established time for analysis of response effectiveness and command timeline metrics without requiring manual data re-entry or reconciliation between different data sources.
Separate Read Permission from Update Permission
What - The permission structure for Incident Reporting has been refined to separate Read permissions from Update permissions, ensuring users with Read access can view complete report contents without the ability to edit, start, or modify them. Users granted only Read permission will see the 👁️ (view) icon for reports, while the ▶️ (start) and ✏️ (edit) icons are hidden. This permission structure applies to both NERIS and Canada/NFIRS environments, with the system automatically defaulting to read-only display when edit and start permissions are not granted.
Why - This enhancement was implemented to improve data integrity and user confidence by preventing unintended report modifications, ensuring that users assigned view-only access cannot accidentally alter critical incident documentation while still maintaining full visibility into report details.
How - To configure read-only access for Incident Reporting:
Navigate to Admin → Roles and Permissions
Select the target role you wish to configure (e.g., Fire Department Admin - Client X)
Under Incident Reporting, General>Incidents select only the Read checkbox
Ensure Create, Update, and Delete permissions remain unchecked
Save your changes
Users assigned to this role will now see the 👁️ (view) icon for reports and can view complete report contents
Users will not see ▶️ (start) or ✏️ (edit) icons and cannot modify reports
Note: This permission structure applies to both NERIS and Canada/NFIRS reporting systems
Note: The system automatically defaults to read-only display when edit and start permissions are not granted
Use Case - A fire department has training officers who need to review completed incident reports for training scenario development but should not be able to modify official documentation. The department administrator creates a "Training Officer - Read Only" role with only the Read permission enabled under Incident Reporting. When a training officer logs in and accesses the incident list, they see the 👁️ (view) icon next to each report and can open and review all report details including narratives, apparatus information, and timelines. However, they cannot see the edit or start icons, preventing them from accidentally modifying any incident data. This ensures the training officers have the information they need for training purposes while maintaining the integrity of official incident records that may be used for state reporting or legal documentation.
Validate Aiding Departments Have FDID or NERIS Entity ID
What - Enhanced validation has been introduced for Aiding Departments to ensure each department has a valid FDID (NFIRS) or NERIS Entity ID before saving. The system displays real-time error indicators including a red border, exclamation icon, and inline error message ("Department is missing an associated ID") when attempting to save a department without the required ID, blocking the save action until a valid ID is provided. An error counter in the Aiding Departments section displays the number of incomplete records, and the system prevents duplicate FDID/NERIS Entity IDs with a specific error message. When transitioning from NFIRS to NERIS, existing Aiding Departments are retained but flagged as incomplete if missing Entity IDs, prompting administrators to complete the required information.
Why - This enhancement was implemented to prevent incomplete data submissions to NFIRS/NERIS systems, ensuring accurate reporting, compliance with state requirements, and reliable funding metrics by enforcing that all aiding departments have proper identification before being used in incident reports.
How - To ensure Aiding Departments have valid identification:
Navigate to Setup → Aiding Departments
When adding or editing a department, ensure the FDID (NFIRS) or NERIS Entity ID field is completed
If you attempt to save without an ID, you'll see:
A red border and exclamation icon on the ID field
An inline error message: "Department is missing an associated ID"
The record cannot be saved until a valid ID is entered
Review the Error counter in the Aiding Departments section to identify how many incomplete records require attention
For flagged incomplete records, add the missing FDID or NERIS Entity ID and save to clear the error flag
Note: The system prevents duplicate FDID/NERIS Entity IDs and will display an error message if you attempt to reuse an existing ID
Note: When transitioning from NFIRS to NERIS, existing Aiding Departments are retained but will be flagged if missing NERIS Entity IDs until corrected
Use Case - A fire department administrator is setting up their mutual aid partners in the Aiding Departments section before submitting their quarterly NERIS report. They add "County Fire District 5" as an aiding department but forget to enter the NERIS Entity ID. When they attempt to save, the system displays a red border around the Entity ID field with an exclamation icon and the message "Department is missing an associated ID," preventing the save. The administrator sees that the Error counter shows "1 incomplete record" in the Aiding Departments section. They obtain the correct NERIS Entity ID (12345) from their regional coordinator, enter it in the field, and successfully save the department. Later, when documenting a mutual aid incident where County Fire District 5 responded, the administrator can confidently select this department knowing it has the proper Entity ID for accurate state reporting and funding allocation tracking.
What - The duplicate incident validation process within the importing tool has been enhanced to accurately identify unique incidents by aligning time zones between the database and imported files, and by including the FDID field as part of the validation criteria. The system now converts both database-stored timestamps and imported file timestamps to the client's local time zone before comparison, and uses Incident Number, Exposure, Alarm Date/Time (in client time zone), and FDID as validation parameters. This prevents valid incidents from being incorrectly flagged as duplicates and significantly reduces false positive "Incident already exists" errors.
Why - This enhancement was implemented to resolve validation inconsistencies that caused legitimate incidents to be incorrectly flagged as duplicates due to time zone mismatches and missing FDID differentiation, improving import accuracy and reducing workflow disruptions during bulk incident imports.
How - No manual configuration is required to benefit from this improvement:
Import incident files using the standard importing tool process
The system will automatically:
Convert both imported file timestamps and database timestamps to your client's local time zone for comparison
Compare incidents using Incident Number, Exposure, Alarm Date/Time (in client time zone), and FDID
Flag an incident as duplicate only if all four parameters match
Identify incidents as unique if FDID or Alarm Date/Time differ, even if Incident Number and Exposure match
Note: Incidents with the same Incident Number but different FDIDs will now be correctly identified as unique records
Note: Time zone alignment ensures incidents are not incorrectly flagged due to UTC conversion discrepancies
Use Case - A regional fire authority manages multiple fire departments, each with their own FDID, using a centralized incident management system. Department A (FDID 12345) and Department B (FDID 67890) both use the incident numbering format "2024-001" at the start of each year. When the administrator imports incident files for both departments, Department A's incident "2024-001" occurred on January 1, 2024 at 10:30 AM local time, while Department B's incident "2024-001" occurred on January 1, 2024 at 2:45 PM local time. Previously, these incidents might have been incorrectly flagged as duplicates due to time zone conversion issues or because the FDID wasn't considered in validation. With this enhancement, the system correctly identifies these as two unique incidents because they have different FDIDs, preventing false duplication errors and allowing both incidents to import successfully without requiring manual intervention or renumbering.
Related Articles
Fire Documentation Release Notes : October 2025
New Features 1. AI for NFIRS Canada What - Artificial intelligence capabilities have been introduced specifically for Canadian clients following the NFIRS (National Fire Incident Reporting System) standard, leveraging Deepgram and Bedrock endpoints ...
Fire Investigations Release Notes - October 2025
Video New Features CAD Integration for Fire Investigation Module What - The Fire Investigation (FI) module now supports automatic creation and population of investigation records from CAD data using the existing NFIRS notification structure. When a ...
Health & Wellness Release Notes - September 2025
Video Coming Soon New Features 1. Importing NFIRS/NERIS Data into Exposures What - A new "Import Fire Report Data" feature has been added to the Exposures module, enabling users to import and map fire report data directly into exposure records with ...
Fire Investigations Release Notes - September 2025
Video Coming Soon New Features 1. Add Incident Date & Time to Investigations What - A new Incident Date & Time field has been added to the Investigations form as part of the Fire Incident Data section, complementing existing Arrival and Departure ...
Release Notes - Fire Incident Documentation
In order to provide you with more detailed information on our updates we have broken the Release Notes down by module. New Features 1. Default and Error Workflows. What: This feature enables users to create default and error workflows for the ...