Fire Documentation Release Notes : August 2025

Fire Documentation Release Notes : August 2025

Video

Coming Soon

New Features

1. NERIS - Update Stations and Add Attempts to Export List
  • What - Enhanced update functionality for Station records within NERIS integration now ensures all update attempts, whether successful or failed, are consistently recorded and visible in the Export List. The system intelligently determines whether to create or update stations based on existing NERIS identifiers and logs all API interactions for improved visibility and debugging of NERIS synchronization operations.
  • Why - This enhancement was implemented due to customer request to improve traceability and debugging capabilities for NERIS station synchronization, ensuring administrators can identify and resolve sync issues by providing complete visibility into all station update attempts and their outcomes.
  • How - Station updates are automatically managed through enhanced NERIS integration:
    • When a Station is updated in First Due, the system evaluates NERIS synchronization needs
    • If no neris_id exists, createStation API is called in NERIS
    • If neris_id is present and NERIS-relevant fields changed, updateStation API is called
    • If no NERIS-relevant fields changed, no API call is made
    • All attempts are recorded in the Export List regardless of data validity
    • View Export List to see detailed API responses with clear success/failure indicators
    • Note: Update attempts are made even with invalid data to ensure failure visibility
    • Note: Export List displays comprehensive sync attempt history with detailed error information
  • Use Case - When a fire department updates Station 15's address information, the system automatically attempts to sync this change with NERIS and logs the attempt in the Export List. If the station record contains invalid coordinate data that causes the NERIS update to fail, administrators can immediately see the failure in the Export List with the specific NERIS API error response, allowing them to correct the data issue and retry the synchronization rather than wondering why station information isn't updating in NERIS reporting.


2. NERIS - Delete Apparatus and Add Attempts to Export List
  • What - Apparatus deletion functionality has been enhanced with NERIS integration, allowing deletion attempts to be automatically sent to NERIS regardless of data validity, ensuring all deletion operations are captured and displayed in the Export List. This provides complete transparency into backend deletion operations and improves monitoring capabilities for NERIS synchronization processes.
  • Why - This enhancement was implemented due to customer request to improve visibility and troubleshooting capabilities for apparatus deletion operations between First Due and NERIS, ensuring administrators can track and resolve failed deletion attempts that may impact data consistency across systems.
  • How - Apparatus deletions are automatically synchronized with NERIS through enhanced integration:
    • When an apparatus/unit is deleted in First Due, deletion payload is automatically generated
    • Delete Unit request is sent to NERIS via API wrapper functionality
    • Deletion attempt is made regardless of data validity or completeness
    • NERIS processes the deletion request and returns success or failure response
    • All outcomes are recorded in the NERIS Export List with detailed response information
    • View Export List to monitor deletion attempts and identify failures
    • Note: Failed attempts include detailed NERIS API responses for troubleshooting
    • Note: Export List clearly marks successful versus failed deletion operations
  • Use Case - When a fire department retires Engine 7 and deletes it from their apparatus roster, the system automatically attempts to delete the corresponding unit record in NERIS and logs this attempt in the Export List. If the deletion fails because the apparatus has incomplete NERIS identification data, administrators can immediately see the failure notification with the specific NERIS error message in the Export List, allowing them to understand why the unit wasn't removed from NERIS reporting and take appropriate corrective action.


3. NERIS - Update Apparatus and Add Attempts to Export List
  • What - Apparatus update functionality now includes automatic synchronization with NERIS, intelligently determining whether to create or update units based on existing NERIS identifiers while logging all attempts in the Export List. The system selectively triggers API calls only when NERIS-relevant fields are modified and provides complete visibility into synchronization outcomes, including detailed failure responses for troubleshooting.
  • Why - This enhancement was implemented due to customer request to ensure apparatus data consistency between First Due and NERIS while providing administrators with comprehensive monitoring and error tracking capabilities for all synchronization attempts, successful or failed.
  • How - Apparatus updates are automatically managed through intelligent NERIS synchronization:
    • When an apparatus is updated in First Due, the system evaluates synchronization requirements
    • If no neris_id exists, createUnit is called in NERIS
    • If neris_id is present, updateUnit is called in NERIS
    • API calls are triggered only when NERIS-relevant fields are modified
    • All attempts are logged in Export List regardless of data validity
    • Failed attempts display detailed NERIS API error responses for debugging
    • View Export List to monitor all apparatus update attempts and outcomes
    • Note: Invalid data payloads are still sent to NERIS to ensure failure visibility
    • Note: Export List clearly identifies successful updates versus failures with detailed error information
  • Use Case - When a fire department updates Engine 3's pump capacity from 1500 GPM to 1750 GPM after equipment upgrades, the system automatically detects this NERIS-relevant change and attempts to update the unit information in NERIS. If the update fails due to invalid serial number data in the apparatus record, administrators can immediately see the failure in the Export List with the specific NERIS validation error, allowing them to correct the serial number field and ensure the apparatus information is properly synchronized between both systems for accurate reporting.

Enhancements

1. Auto-Population of Call Arrival from Call Answered for Specific Reports
  • What - A data migration has been implemented to automatically populate missing "Call Arrival" fields using corresponding "Call Answered" values for incident reports in Pending Authorization or Authorized status created after June 1, 2025. This targeted enhancement addresses data consistency issues and prevents validation errors that occur when reports advance through the authorization workflow with incomplete time stamp information.
  • Why - This enhancement was implemented due to customer request to resolve validation errors that occurred when incident reports missing Call Arrival data bypassed normal validation workflows, causing system issues when these reports were later moved from Authorized to Completed status during the standard incident processing cycle.
  • How - The auto-population process runs automatically for qualifying incident reports:
    • The system identifies NERIS reports in Pending Authorization or Authorized status
    • Reports must be missing Call Arrival (psap_call_date) data and created after June 1, 2025
    • For matching reports, the Call Arrival field is automatically populated with the existing Call Answered field value
    • The migration preserves existing report status and workflow progression
    • Note: Only reports meeting all specified criteria are affected by the auto-population
    • Note: The process does not alter report status or interrupt normal authorization workflows
    • Note: Validation processes will function correctly after Call Arrival data is populated
  • Use Case - A fire department that submitted an incident report with a Call Answered time of 14:32:15 but missing Call Arrival data will have their report automatically updated with the same timestamp in the Call Arrival field during the migration process. This ensures that when the fire chief reviews and moves the report from Authorized to Completed status, the validation system will function properly without generating errors, allowing the report to progress through the normal workflow while maintaining accurate incident timeline documentation for regulatory compliance and operational analysis.



2. Change Order of Dispatch Call Fields in NERIS Form
  • What - The Dispatch - Call fields in the NERIS form have been reordered to align with the NERIS Technical Guide standards, improving data clarity and user experience by presenting fields in chronological sequence. The fields now appear as Call Arrival, Call Answered, and Call Created, reflecting the logical timeline of dispatch events while maintaining all existing validation and data integrity requirements.
  • Why - This enhancement was implemented due to customer request to correct field ordering inconsistencies that did not align with NERIS validation rules and official standards, creating confusion during data entry and potentially affecting compliance with NERIS reporting requirements.
  • How - The updated field order is automatically applied to all NERIS forms:
    • Call Arrival now appears first in the Dispatch - Call section
    • Call Answered appears second in the sequence
    • Call Created appears third and final in the field order
    • Existing time sequence validation ensures Call Arrival ≤ Call Answered ≤ Call Created
    • When "Is your PSAP and Dispatch Center the same?" is set to false, Dispatch Notified field is enabled
    • Dispatch Notified must be later than or equal to Dispatch - Call Arrival time
    • Note: This is a UI-only change with no backend or database modifications required
    • Note: All existing data and validation logic remain unchanged
  • Use Case - A fire department dispatcher completing a NERIS incident report will now see the Dispatch - Call fields in their natural chronological order, starting with Call Arrival (when the call was received), followed by Call Answered (when response was initiated), and ending with Call Created (when the incident record was generated in the system). This logical sequence reduces data entry errors and ensures compliance with NERIS Technical Guide standards, particularly for departments with separate PSAP and dispatch centers where the Dispatch Notified field timing validation becomes critical for accurate incident timeline documentation.






3. ECOMM - Update Header to Show Dispatch Location
  • What - The Dispatch Location field has been restored to both the Incident Report Header and Incident Highlights Popout, ensuring critical location information is readily accessible to users during incident management workflows. The field appears with consistent formatting that matches the existing Incident Location display, maintaining visual uniformity across the interface while providing essential operational data.
  • Why - This enhancement was implemented due to customer request to address a regression that occurred during the UI update process, which unintentionally removed the Dispatch Location field from key interface areas, impacting operational efficiency and user access to critical incident location information.
  • How - The Dispatch Location field is automatically displayed in updated interface locations:
    • In the Incident Report Header, Dispatch Location appears directly after the Incident Date/Time
    • In the Incident Highlights Popout, Dispatch Location is positioned between Incident Date/Time and Dispatch Unit Codes
    • The field uses the same formatting, font, spacing, and alignment as Incident Location for consistency
    • Note: The field restoration applies to both NFIRS and NERIS client interfaces
    • Note: No additional configuration is required as the field displays automatically where dispatch location data exists
    • Note: Styling maintains visual consistency with existing interface elements
  • Use Case - A fire department dispatcher reviewing an active incident can now immediately see both the original incident location and the dispatch location in the header section, allowing them to quickly verify if responding units are being directed to the correct address versus where the incident was initially reported. This is particularly valuable for incidents where the dispatch location differs from the reported incident location, such as multi-building complexes or situations where access points vary from the actual emergency location, ensuring proper resource deployment and response coordination.


NFIRS Report


NERIS Report




4. ECOMM - Add Response Mode to NFIRS Notification Table for CAD Team Mapping
  • What - A new response_mode field has been added to the nfirs.notification_apparatus table to support CAD team mapping requirements for ECOMM operations, enhancing data alignment and interoperability between internal systems and external consumers. The field stores Response Mode information associated with each apparatus notification and is integrated with existing API endpoints to ensure full system visibility and accurate incident tracking capabilities.
  • Why - This enhancement was implemented due to customer request to improve data mapping capabilities between CAD systems and ECOMM operations, enabling more accurate apparatus response tracking and enhanced operational analysis through better integration of response mode information across platforms.
  • How - The response_mode field is automatically integrated into apparatus notification workflows:
    • The response_mode column is available in the nfirs.notification_apparatus table for data storage
    • CAD team maps response mode values from Apparatus → Apparatus Details → Response Mode
    • response_mode field is included in API request bodies when creating units via API
    • Refresh from CAD function seamlessly integrates with the new field
    • If a unit is removed, refresh process restores it with correct response_mode value
    • If only response_mode is deleted, refresh retrieves and repopulates from CAD system
    • Note: API schemas and responses have been updated to include the response_mode field
    • Note: External systems can retrieve response_mode data for operational and analytical purposes
    • Note: Field maintains accurate reflection of apparatus response data for reliable incident tracking
  • Use Case - When a fire engine responds Code 3 (emergency response with lights and sirens) to a structure fire, the CAD system now captures and maps this response mode information to the apparatus notification record, allowing incident commanders and analysts to distinguish between emergency and non-emergency responses in their operational reports. If the response mode data is accidentally removed during system maintenance, the "Refresh from CAD" function automatically restores the correct Code 3 designation, ensuring consistent and accurate documentation of how each apparatus responded to the incident for compliance reporting and operational analysis.



5. NERIS Call Get Entity Endpoint and Omit Duplicate Stations During Registration
  • What - The NERIS registration process now integrates with the NERIS Get_Entity endpoint to automatically check existing station data before registration, preventing duplicate station records and ensuring seamless data transition. The system compares station lists between NERIS and First Due platforms, automatically associates existing stations, creates missing stations in First Due from NERIS data, and maintains current logic for First Due-only stations.
  • Why - This enhancement was implemented due to customer request to address issues where stations manually registered in NERIS prior to First Due migration were causing duplicate station_neris_id values, creating data inconsistencies and registration complications during the platform transition process.
  • How - The enhanced registration process automatically manages station synchronization:
    • The system calls the NERIS Get_Entity endpoint during client NERIS activation
    • Station lists from both NERIS and First Due are automatically compared
    • For stations existing in both systems, the station_neris_id from NERIS is associated with the existing First Due station
    • For stations in NERIS only, new stations are automatically created in First Due using NERIS data
    • For stations in First Due only, existing registration logic is maintained
    • Note: The process runs automatically during NERIS switching with no user intervention required
    • Note: All existing station data and associations are preserved during the synchronization
  • Use Case - A fire department that previously registered Station 12 and Station 15 manually in NERIS before migrating to First Due will no longer encounter duplicate registration errors. When activating NERIS integration, the system automatically identifies these existing stations, links them to the corresponding First Due records, and creates any additional NERIS-registered stations that don't yet exist in First Due, ensuring a complete and accurate station roster across both systems without manual cleanup or duplicate data management.



6. Canada - Remove Wildland Form Setting
  • What - Canadian fire departments no longer need to configure the "Do you use Wildland Form for Outdoor Fires?" setting in Fire Incident Setup, as Wildland form fields are now activated directly through the Wildland toggle on incident forms. This streamlined approach removes administrative setup requirements while providing more intuitive access to Wildland reporting fields based on real-time incident needs.
  • Why - This enhancement was implemented due to customer request from Canadian jurisdictions to simplify the Wildland form activation process, eliminating unnecessary configuration steps that were designed for NFIRS reporting workflows but not required for Canadian fire reporting standards.
  • How - Wildland form access is now controlled directly through the incident form:
    • The "Do you use Wildland Form for Outdoor Fires?" setting is hidden from Fire Incident Setup → General for Canadian users
    • Wildland toggle on the incident form now directly controls field visibility
    • Activating the Wildland toggle displays all relevant Wildland fields regardless of incident type
    • No administrative pre-configuration is required for Wildland form access
    • Note: This change applies only to Canadian fire department users
    • Note: Previously configured settings will not affect the new toggle-based functionality
  • Use Case - A Canadian fire department responding to a grass fire can now immediately access Wildland reporting fields by simply activating the Wildland toggle directly on the incident form, without requiring their system administrator to pre-configure Wildland settings in the administrative setup. This allows incident commanders to make real-time decisions about whether Wildland data collection is needed based on the specific characteristics of each outdoor fire, improving reporting flexibility while reducing administrative overhead for Canadian fire services.










7. Import Wizard - Update Incident Report Template
  • What - The Incident Report import templates have been enhanced to support additional optional data fields including Officer in Charge, Remarks/Narrative, Response Mode, and Station, improving the flexibility and completeness of incident data imports across all supported jurisdictions. The enhancement maintains full backward compatibility while expanding data capture capabilities for NERIS, NFIRS, and all Canadian systems.
  • Why - This enhancement was implemented due to customer request to provide more comprehensive incident data import capabilities, enabling fire departments to capture detailed operational information during bulk data imports while maintaining compatibility with existing import workflows.
  • How - Access the enhanced template through the Import Wizard interface:
    • Navigate to Import Wizard and select Incident Report template
    • Download the updated template with new optional fields available
    • Optionally populate additional fields: Officer in Charge (name or ID), Remarks/Narrative (free-text description), Response Mode (response type), and Station (associated station)
    • Upload the completed template using standard import process
    • Note: New fields are completely optional and existing templates will continue to function
    • Note: Enhancement applies to NERIS, NFIRS, and all Canadian system imports
    • Note: Users not utilizing new fields require no workflow changes
  • Use Case - A fire department migrating historical incident data can now include critical details like the Officer in Charge information and specific response modes during bulk imports, ensuring comprehensive incident records from the start. For example, importing a structure fire incident can now include "Captain Smith" as Officer in Charge, "Code 3 - Emergency Response" as Response Mode, and detailed narrative information about the incident response, eliminating the need to manually update hundreds of records after import to meet departmental documentation standards.






8. Canada - Ensure All Fields Available for Workflows
  • What - Workflow configuration capabilities have been enhanced to ensure all UI fields, including Custom Questions and standard fields, are now available in the Field dropdown across all Canadian workflows. This comprehensive update addresses previous gaps where certain fields were missing from workflow configurations, particularly impacting British Columbia workflows and Hide action functionality.
  • Why - This enhancement was implemented due to customer request to resolve field availability issues in workflow configurations that prevented Canadian fire departments from creating comprehensive workflow rules using all available form fields, particularly affecting British Columbia's workflow setup capabilities.
  • How - Enhanced field availability is automatically applied to all Canadian workflow configurations:
    • Access Workflows configuration in any Canadian jurisdiction
    • All standard fields and Custom Questions are now visible in the Field dropdown
    • Configure workflow actions including Show/Hide, Set Value, and Require using any UI field
    • Create comprehensive workflow rules with full field selection flexibility
    • Note: Update applies automatically to all Canadian provinces and regions
    • Note: All workflow action types that utilize field selection are enhanced
    • Note: No user action required as changes are applied to existing CA workflow environments
  • Use Case - A British Columbia fire department can now create a workflow that hides custom questions related to "Wildland Fire Suppression Resources" when the incident type is set to "Structure Fire," ensuring form fields remain relevant to the specific incident type. Previously, these custom question fields were not available in the workflow Field dropdown, preventing this type of conditional form logic and forcing users to see irrelevant fields regardless of incident context.



    • Related Articles

    • Fire Investigation Release Notes : August 2025

      Video Coming Soon New Features 1. Field Management - Custom Questions within the Investigation Form What - The Investigation form now displays custom questions that were previously configured through Field Management, appearing in their designated ...

    • Health & Wellness Release Notes : August 2025

      Video Coming Soon New Features 1. Field Management - Add Custom Questions to Field Management What - A new Custom Questions subsection has been added under Exposure Setup → Field Management, enabling users to create and configure custom fields for ...

    • ePCR Release Notes - August 2025

      Video Coming Soon New Features 1. QA/QI - AI Generated Feedback Integration for QA/QI Module What - The QA/QI module now integrates AI-generated feedback capabilities that automatically analyze Patient Care Reports and provide comprehensive review ...

    • Fire Documentation Release Notes - June 2025

      Video New Features 1. Retry Mechanism for NERIS Export Failures Introduce a retry strategy for handling failures in data export to NERIS, covering both API transmission issues and database persistence errors. How it works: When a data export to NERIS ...

    • Release Notes - Assets

      In order to provide you with more detailed information on our updates we have broken the Release Notes down by module. New Features 1. A completed checklist may now be deleted from the Checklist History An option was to delete completed checks from ...