1 - New Email Option for Timed-out Ad Hoc Downloads
What - A new fallback email delivery system has been implemented for Ad Hoc report downloads that experience timeout errors during file generation. When users attempt to download large reports (CSV, PDF, or XML) and encounter timeout issues, the system now automatically detects these failures and presents users with an option to receive their report via email instead. This enhancement includes centralized file handling with improved naming consistency, secure storage for large files with short-lived access tokens, and streamlined download processes that eliminate the frustration of failed downloads and the need for users to restart their report generation from scratch.
Why - Large Ad Hoc reports frequently experienced timeout errors during the download process, leaving users without their requested data and requiring them to restart the entire report generation workflow. This created significant user frustration, increased support tickets, and reduced operational efficiency for public safety personnel who rely on timely access to critical reporting data. The email fallback option ensures users can reliably receive their reports regardless of file size or processing complexity, while the centralized file handling system improves overall system reliability and reduces the burden on technical support teams.
How - The email fallback option activates automatically when timeout conditions are detected during report downloads:
When a timeout occurs during report generation, a prompt will appear asking "This has taken longer than expected. Do you want to send it by mail?"
Click "Yes" to open the Send by Email modal with pre-filled report settings
Verify your email address and any additional recipients in the modal
Click "Send" to queue the report for email delivery
You will receive the completed report as an email attachment once processing is complete
For successful direct downloads, files will be stored securely and accessed through a temporary download link
All exported file names now include consistent timestamps and sanitized formatting across all download methods
Use Case - An administrator needs to export a comprehensive incident report covering six months of data in CSV format for court proceedings. During the download attempt, the large dataset causes a timeout error. Instead of losing their work and starting over, the administrator receives the timeout prompt and chooses the email option. They enter their work email address, and within minutes receive the complete report as an email attachment, allowing them to proceed with case preparation without delay. Similarly, an analyst generating annual fire statistics can now confidently request large PDF reports knowing that if direct download fails, they'll automatically receive the data via email without having to recreate their report parameters.
Example of the Timeout Error:
Example of the Email Request:
Feature Enhancements
1 - Added "Incident Report Weather Fields" Child Data Source for NERIS
What - A new child data source called "Incident Report Weather Fields" has been added to the NERIS data framework, providing comprehensive weather-related attributes for incident analysis. This enhancement expands weather data coverage by combining existing weather fields with new NERIS weather fields including cloudiness, rain, snow, wind gust, visibility, and pressure measurements. The data source maintains a 1:1 relationship with parent Incident Report records, ensuring consistent row counts, and delivers natural language values instead of coded entries for improved readability.
Why - Public safety operations are significantly influenced by environmental conditions, yet previous weather data capabilities were limited and difficult to analyze effectively. Emergency responders need comprehensive weather context to understand how environmental factors impact incident frequency, response times, and operational safety. The expanded weather data source enables deeper analytical insights into weather-related incident patterns and supports evidence-based operational planning.
How - Access the new weather fields by selecting the child data source when building Ad Hoc reports:
Navigate to Ad Hoc Reports and select Incident Report (NERIS) as your primary data source
In the data source selection area, locate and check "Incident Report Weather Fields" as a child data source
Select from available weather columns organized by source:
From f_incident_report: Temperature, Temperature (Celsius/Fahrenheit), Wind Speed, Humidity, Weather Type
New from neris_weather: Cloudiness (weather_cloudiness), Rain (precipitation_rain), Snow (precipitation_snow), Wind Gust (wind_gust), Visibility (weather_visibility), Pressure (weather_pressure)
Apply sorting, grouping, summary functions, and filtering criteria to weather columns as needed
Weather values from NERIS fields will display in natural language format for easier interpretation
Use Case - A fire department analyst investigating winter emergency response effectiveness creates a report combining incident response times with detailed weather metrics including temperature, snow precipitation, wind gust speeds, and visibility measurements. The analysis reveals that incidents during low visibility conditions with wind gusts above 25 mph show longer response times, enabling the department to adjust staffing during similar forecasts. An EMS supervisor can analyze how humidity and temperature combinations affect heat-related calls, using this data to develop community health advisories and optimize ambulance deployment during extreme weather events.
2 - Added "Incident Report Emerging Hazards" Child Data Source for NERIS
What - A new child data source called "Incident Report Emerging Hazards" has been added to the NERIS data framework to capture modern and evolving risk factors not previously available in NFIRS. This enhancement allows agencies to document and analyze emerging hazards such as battery energy storage systems, electric vehicles, photovoltaic systems, and corrugated stainless steel (CSST) ignition sources. The data source supports a 1:M relationship since multiple hazards may be associated with a single incident, and provides natural language values for improved readability and external reporting compatibility.
Why - Modern fire and emergency incidents increasingly involve new technologies and materials that present unique challenges not covered by traditional NFIRS reporting categories. Fire departments need to track and analyze emerging hazards like electric vehicle fires, solar panel complications, and battery storage incidents to develop appropriate response strategies and safety protocols. This data source enables agencies to identify trends in these evolving risk categories, supporting evidence-based policy development and specialized training programs for emerging hazard scenarios.
How - Access emerging hazards data by adding the child data source to your NERIS reports:
Navigate to Ad Hoc Reports and select Incident Report (NERIS) as your primary data source
In the child data sources section, locate and check "Incident Report Emerging Hazards"
The system will establish a 1:M relationship allowing multiple hazard entries per incident
Select from available hazard categories including Battery/Energy Storage (EES), electrification and re-ignition risk, suppression approaches, power generation hardware (photovoltaics), and CSST ignition/lightning vulnerabilities
Apply standard Ad Hoc functions including sorting, grouping, summary rows, and criteria filtering to all emerging hazard columns
Data will display in natural language format for easier analysis and reporting
Use Case - A fire department training officer analyzes incidents involving electric vehicle fires over the past year to develop specialized response protocols. Using the emerging hazards data source, they identify patterns in suppression approaches, re-ignition frequency, and resource requirements for EV incidents. The analysis reveals that incidents involving battery energy storage require extended monitoring periods and specialized foam applications, leading to updated standard operating procedures and equipment procurement recommendations. Similarly, a fire prevention specialist can track photovoltaic system incidents to identify common failure modes and develop inspection protocols for solar installations in their jurisdiction.
3 - Added "Incident Report Chemicals" Child Data Source for NERIS
What - A new child data source called "Incident Report Chemicals" has been added to the NERIS data framework to document hazardous chemical involvement in incidents. This enhancement captures detailed chemical information including material names, estimated volumes/weights, physical states, release conditions, and DOT hazard classifications. The data source supports a 1:M relationship with each row representing a chemical entry tied to an incident, and provides natural language translations for code values to improve readability.
Why - Hazardous material incidents require detailed documentation of chemical involvement that traditional NFIRS reporting could not adequately capture. Emergency response agencies need comprehensive chemical data to analyze hazmat incident patterns, track release causes, and develop targeted prevention strategies for chemical-related emergencies.
How - Access chemical incident data by adding the child data source to your NERIS reports:
Navigate to Ad Hoc Reports and select Incident Report (NERIS) as your primary data source
In the child data sources section, locate and check "Incident Report Chemicals"
The system will establish a 1:M relationship allowing multiple chemical entries per incident
Select from available chemical tracking fields including material names, volumes/weights, physical states, release conditions, and DOT hazard classifications
Apply standard Ad Hoc functions including sorting, grouping, summary rows, and criteria filtering
Code values will automatically display as readable text for easier analysis
Use Case - A HazMat team leader analyzes chemical release incidents to identify common causes and improve response protocols. Using the chemicals data source, they discover that liquid petroleum gas releases in residential areas frequently involve corroded valve connections, leading to targeted inspection programs. An emergency planner can track incidents involving specific DOT hazard classes to develop specialized equipment requirements and training programs for chemical response teams.
4 - Added "Completed At" Timestamps to f_incident_report
What - Two new timestamp columns have been added to the Incident Report data source to track when reports are marked as completed: "First Date/Time Completed At" captures the earliest completion timestamp, while "Last Date/Time Completed At" records the most recent completion. These fields are derived from the incident report history log and support the complete workflow lifecycle including re-opening and re-completion scenarios, with null values displayed for reports that have never been completed.
Why - Agencies need visibility into report completion timelines to analyze workflow efficiency, assess compliance with reporting standards, and identify bottlenecks in their incident documentation processes. Without completion timestamps, supervisors cannot effectively audit report turnaround times or track productivity metrics across their departments.
How - Access the new completion timestamps in your Incident Report data source:
Navigate to Ad Hoc Reports and select Incident Report as your data source
Locate the new columns "First Date/Time Completed At" and "Last Date/Time Completed At" in the available fields
Use these timestamp fields for filtering (incidents completed after specific dates), grouping and aggregation (average completion delays), or sorting to identify recent completions
Apply standard Ad Hoc functions including criteria filtering, summary rows, and date-based grouping
Note that both fields will show null values for reports that have never been completed
Use Case - A fire department supervisor analyzes report completion efficiency by comparing first and last completion timestamps to identify reports requiring multiple revisions. They discover that certain incident types consistently require re-opening and re-completion, leading to targeted training for report writers. An agency administrator can track compliance with 48-hour reporting requirements by filtering incidents where the first completion timestamp exceeds the incident date by more than two days.
5 - "Incident Report Property Fields" Child Data Source for NERIS
What - A new child data source called "Incident Report Property Fields" has been added to expand property-related reporting capabilities within the NERIS framework. This enhancement combines existing NFIRS property fields (Property Loss, Contents Loss, Structure Type) with new NERIS-specific columns including Location Use Type, Specific Use, Location in Use, Primary Indoors, People Present, Location Used as Intended, and Reason Location Not in Use. The data source maintains a 1:1 relationship with Incident Report (NERIS) and provides natural language values for improved readability.
Why - Property-related incident analysis requires comprehensive data about building usage, conditions, and loss metrics that traditional reporting could not adequately capture. Fire prevention teams and analysts need detailed property information to identify risk patterns, assess compliance issues, and develop targeted prevention strategies based on actual property usage and conditions.
How - Access expanded property data through the new child data source:
Navigate to Ad Hoc Reports and select Incident Report (NERIS) as your primary data source
In the child data sources section, locate and check "Incident Report Property Fields"
Select from available property fields including existing NFIRS metrics (Property Loss, Contents Loss, Structure Type, Building Status) and new NERIS fields (Location Use Type, People Present, Location Used as Intended)
Apply standard Ad Hoc functions including filtering, grouping, summary rows, and criteria-based reporting
NERIS fields will display natural language descriptions instead of coded values
Use the 1:1 relationship to analyze property conditions alongside incident details without data inflation
Use Case - A fire prevention officer analyzes residential fire incidents to identify properties where locations were not used as intended, discovering that many kitchen fires occur in converted spaces lacking proper ventilation. A department analyst compares property loss versus contents loss across different structure types to optimize resource allocation and develop targeted prevention programs for high-risk property categories.
What - Ad Hoc Summary Reports now include a new "By Calendar Month" parsing option for all Date and Datetime columns in Row Groups and Column Groups. This enhancement allows users to group data strictly by calendar month (January, February, etc.) independent of the year, enabling cross-year monthly comparisons and seasonal trend analysis. The feature works seamlessly with existing Ad Hoc functionality including grouping, criteria, sorting, visualization, and charting capabilities while respecting timezone adjustments for deployment accuracy.
Why - While Ad Hoc previously supported linear time series reporting with options like "By Year" or "By Month and Year," users needed the ability to compare values across calendar months over multiple years for seasonal analysis and trend identification. This enhancement addresses critical use cases such as comparing January incident counts across multiple years, analyzing seasonal fire risks during summer months, identifying winter EMS spikes, and performing year-over-year workload comparisons for specific months to support strategic planning and resource allocation decisions.
How - To use the new Calendar Month parsing option:
Navigate to Ad Hoc and create a new Summary Report
Select a Date/Datetime column in either Row Groups or Column Groups
Choose By Calendar Month from the available parsing options
The system will group values by month only, producing up to 12 rows (January through December)
For cross-year comparison, set Row Group to Calendar Month and Column Group to Year
When adding a Chart, the same By Calendar Month grouping option will be available for visualization
Feature works with all existing Summary Report functionality including criteria filtering and sorting
Use Case - Fire departments can now analyze seasonal fire incident patterns by comparing July fire counts across the past five years to identify increasing summer fire risks and adjust staffing accordingly. EMS agencies can compare December call volumes year-over-year to better understand winter demand spikes and plan resource deployment. Emergency management teams can evaluate January ice storm responses across multiple years to refine seasonal preparedness strategies, while administrators can compare monthly training completion rates to identify consistent seasonal trends in personnel availability and scheduling conflicts.
7 - Created "NFIRS Deprecated Columns" Data Source
What - A new child data source called "Deprecated NFIRS Fields" has been added to Ad Hoc, providing access to 57 legacy NFIRS columns from the original incident report structure that were not carried over to the NERIS framework. This data source joins with Incident Report (NERIS) via incident_id using a 1:1 relationship to prevent row inflation, enabling users to build hybrid reports combining both NFIRS and NERIS data. The deprecated fields include key legacy elements such as Incident Type (NFIRS), Mobile Property fields, Detector and AES fields, Fire incident context data, and administrative fields, all maintaining their original names and data types with existing UI translations for code-based columns.
Why - The transition to the NERIS framework replaced the legacy NFIRS structure for incident documentation, but some critical NFIRS fields were deprecated and no longer appear in the NERIS dataset. Fire departments require continued access to these legacy fields for compliance reporting, regulatory audits, performance tracking, and operational analysis in 2025, particularly when conducting longitudinal studies and year-over-year comparisons that span the NFIRS-to-NERIS transition period. This enhancement ensures data continuity and prevents gaps in historical trend analysis while maintaining compatibility with current NERIS reporting capabilities.
How - To access deprecated NFIRS fields:
Navigate to Ad Hoc and select Incident Report (NERIS) as the parent data source
Expand the data source selection to view available child data sources
Select Deprecated NFIRS Fields as a child data source to join with the parent
Choose from 57 available legacy fields including Incident Type (NFIRS), Area of Fire Origin, Detector Power Supply, Mobile Property Type, and Extent of Fire Involvement on Arrival
Build criteria combining both frameworks, such as Incident Type (NFIRS) IN (110-118) OR Primary Incident Subgroup = "Fire - Structure Fire"
All existing Ad Hoc functionality including Criteria, Sort, and Summary Rows work seamlessly with the joined data
Performance remains optimal with no significant degradation or timeouts
Use Case - Compliance officers can now generate comprehensive regulatory audit reports that combine current NERIS Primary Incident Subgroup classifications with legacy NFIRS Incident Type codes to demonstrate complete incident coverage across the framework transition. Fire department leadership can track long-term structure fire trends by analyzing both NFIRS codes (110-118) and NERIS "Fire - Structure Fire" classifications in a single report, while performance analysts can compare detector effectiveness data using legacy Detector Type and Operation fields alongside current NERIS incident outcomes to maintain continuity in safety equipment performance metrics and identify improvement opportunities.
Video No video this month. All new enhancements are new Data Sources or new Fields found here when creating an Ad-Hoc report: Enhancements: 1) NFIRS EMS Data Source with NERIS Fields What - The NFIRS EMS data source in Ad Hoc reporting has been ...
Purpose Statement This guide demonstrates the overall navigation of ITM Reports within First Due, providing fire department personnel with comprehensive instructions for managing, reviewing, and processing fire protection system inspection reports. ...
Purpose Statement This guide demonstrates how to resolve or make changes to Initial System Status on ITM Reports within First Due. Fire department personnel use this functionality to track and document the resolution of fire protection system ...
Video New Feature What: Multi-Agency Dataset Sharing Tool Why: Agencies with a Parent / Child data relationship want control of what data is being shared. How: Go to the Reports Module > Set Up > Multi-Agency Dataset Sharing Select the Parent Agency ...
Purpose Statement To demonstrate how to create a new folder in the Report List view for organizing and storing your ad-hoc reports. This feature helps users maintain an organized report structure, making it easier to locate and manage custom reports ...