Fire Documentation Release Notes : August 2025

Fire Documentation Release Notes : August 2025

Video


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.



4. NERIS - Create Hard Coded Validation Requiring Minimum of 1 Apparatus on All Calls
  • What - NERIS calls now enforce a mandatory validation requiring at least one apparatus to be included in every report submission, implementing stricter data integrity requirements aligned with recent NERIS system changes. The system displays a dynamic validation message when no apparatus is selected and automatically clears the validation once apparatus requirements are met, ensuring successful report authorization and compliance with updated NERIS standards.
  • Why - This enhancement was implemented due to customer request to align with new NERIS requirements that enforce stricter validation standards, preventing submission of incomplete incident reports and improving data integrity across all NERIS call documentation while ensuring compliance with updated system specifications.
  • How - Apparatus validation is automatically enforced during NERIS report submission:
    • Initiate NERIS call and select primary incident type as usual
    • If no apparatus is entered, system displays hardcoded message: "At least one Apparatus is required"
    • Validation message prevents report submission until apparatus requirement is satisfied
    • Once apparatus is selected, validation message is automatically cleared
    • Report submission and authorization proceed successfully after apparatus requirements are met
    • Note: Validation appears dynamically when no apparatus is present and disappears when requirement is fulfilled
    • Note: Records can only be authorized when minimum apparatus requirements are satisfied
    • Note: Validation applies to all NERIS call types regardless of incident classification
  • Use Case - A fire department dispatcher creating a NERIS report for a medical assist call will be unable to submit the report if they forget to assign an apparatus, with the system displaying "At least one Apparatus is required" until they select the responding unit. Once they assign Engine 7 to the call, the validation message disappears and they can successfully submit and authorize the report, ensuring all NERIS submissions include proper apparatus assignment for accurate resource tracking and compliance with updated NERIS data integrity requirements.






5. NERIS - Mark Pending Authorization Incidents as Incomplete When Switching from NFIRS to NERIS
  • What - When departments transition from NFIRS to NERIS, all incidents in Pending Authorization status from the last 45 days are automatically reclassified as Incomplete, ensuring proper validation workflows are triggered during re-authorization attempts. The system provides enhanced user messaging through updated confirmation popups and prevents submission failures by enforcing complete validation processes for transitioning incidents.
  • Why - This enhancement was implemented due to customer request to address validation bypass issues that occurred when Pending Authorization incidents transitioned between systems without proper workflow enforcement, causing submission failures and data integrity problems during the NFIRS to NERIS migration process.
  • How - Automatic incident reclassification occurs during system transition:
    • Administrator initiates department transition from NFIRS to NERIS
    • System automatically identifies all Pending Authorization incidents from the last 45 days
    • These incidents are marked as Incomplete to enforce full validation on re-authorization attempts
    • Enhanced confirmation popup displays message: "NOTE: Moving to NERIS will update all Pending Authorization incidents back to Incomplete status in order to trigger validation"
    • Users attempting to re-authorize incidents experience expected validation workflows
    • Note: Only incidents within last 45 days are affected to manage system performance
    • Note: Validation enforcement prevents submission failures during system transition
    • Note: Full workflows and validations are re-triggered for proper data integrity
  • Use Case - A fire department switching from NFIRS to NERIS with 12 incident reports in Pending Authorization status from the past month will see these reports automatically moved to Incomplete status during the transition. When the fire chief later attempts to authorize these reports for NERIS submission, the system will properly enforce all NERIS-specific validation requirements such as mandatory apparatus assignment and data formatting rules, preventing the submission failures that previously occurred when reports bypassed these validation steps during system transitions.



6. NERIS - Only Send Rescue Payload When Fields are Populated
  • What - The system now implements conditional Rescue payload transmission, sending the Rescue payload to NERIS only when at least one of its fields contains data, preventing unnecessary calls with incomplete information and ensuring data integrity. The enhancement includes validation workflows that verify all required Rescue payload fields are completed before transmission, aligning with existing HazSit payload logic for consistent system behavior.
  • Why - This enhancement was implemented due to customer request to eliminate system errors caused by sending incomplete Rescue payloads for all calls regardless of field population, reducing unnecessary API calls and improving data quality by ensuring only complete and relevant rescue information is transmitted to NERIS.
  • How - Conditional payload transmission is automatically managed through enhanced validation logic:
    • System monitors Rescue payload fields during call documentation
    • If no fields are populated, no Rescue payload is sent to NERIS
    • If one or more fields contain data, Rescue payload preparation is triggered
    • Validation workflow ensures all mandatory Rescue payload fields are completed before transmission
    • If validation fails, payload is not sent and appropriate error handling is triggered
    • Only fully valid Rescue payload is transmitted to downstream systems
    • Note: Logic matches existing HazSit payload implementation for consistency
    • Note: Enhancement prevents incomplete payload calls that previously caused system errors
    • Note: Validation ensures data integrity while reducing unnecessary API traffic
  • Use Case - When a fire department responds to a structure fire with no rescue operations, the system will not send a Rescue payload to NERIS since no rescue-related fields are populated, eliminating unnecessary API calls and potential validation errors. However, if the same department responds to a vehicle accident where they document "2 people rescued" and "Extraction equipment used," the system will validate that all required rescue fields are completed before sending the comprehensive Rescue payload to NERIS, ensuring accurate rescue operation documentation while preventing incomplete data transmission.








7. Canada - Script Canadian Workflows Behind SuperAdmin
  • What - A new Provincial Workflows view has been introduced under the SuperAdmin role, centralizing provincial-level workflows for Ontario and New Brunswick into a dedicated administrative interface with strict access control and workflow inheritance capabilities. The system provides view-only access for end users while enabling centralized management of provincial workflows, with built-in support for future province additions and integration with Provincial Shell (Templates) for streamlined deployment.
  • Why - This enhancement was implemented due to customer request to centralize provincial workflow management similar to existing NERIS workflows, ensuring consistent workflow deployment across Canadian jurisdictions while maintaining proper access controls and inheritance structures for parent/child client relationships.
  • How - Provincial workflows are managed through enhanced SuperAdmin capabilities with controlled access:
    • SuperAdmin role gains access to new Provincial Workflows view similar to NERIS Workflows structure
    • Ontario and New Brunswick workflows are scripted and migrated to the new view
    • View-only access prevents end users from editing Provincial Workflows while allowing visibility
    • Workflow inheritance ensures child clients receive parent workflows without modification permissions
    • Script reusability enables future provinces to be added using the same deployment process
    • Provincial Shell (Templates) support for workflow deployment once platform functionality is enabled
    • Note: Child clients inherit workflows from parent clients but cannot edit them
    • Note: Only designated parent clients have Provincial Workflows section populated
    • Note: Inheritance validation ensures proper workflow distribution across client relationships
  • Use Case - A SuperAdmin managing Ontario fire departments can now access the centralized Provincial Workflows view to deploy standardized workflows like "Mandatory Apparatus Assignment" or "NERIS Compliance Validation" across all Ontario clients, ensuring consistent operational procedures. Child fire departments inherit these provincial workflows and can view them for reference but cannot modify the standardized procedures, maintaining regulatory compliance while allowing each department to add their own supplementary workflows for local operational needs without affecting province-wide standards.





8. Retain Custom Questions and Values for Authorized Reports When Enabling or Disabling
  • What - Custom question management has been enhanced to preserve historical data integrity in authorized reports while ensuring incomplete reports reflect current configuration settings. The system now retains disabled custom questions and their values in authorized reports, excludes newly created custom questions from authorized reports to prevent blank entries, and dynamically updates incomplete reports to show the latest custom question configuration for accurate data collection.
  • Why - This enhancement was implemented due to customer request to resolve data inconsistencies where disabling custom questions immediately removed historical values from authorized reports, and newly created custom questions appeared with blank values in completed reports, compromising data accuracy and historical record integrity.
  • How - Enhanced custom question visibility is automatically managed based on report status:
    • When custom question is disabled, authorized reports retain the field and recorded values for historical preservation
    • Incomplete reports no longer display disabled custom questions to reflect current configuration
    • When new custom question is created, authorized reports exclude the new question to prevent blank entries
    • Incomplete reports display new custom questions if required for completion
    • When reports are marked as incomplete, disabled custom questions are removed and newly created or enabled custom questions appear
    • Note: System maintains accurate historical records while ensuring current data collection requirements
    • Note: Dynamic updates ensure incomplete reports reflect latest custom question configuration
    • Note: Enhancement provides seamless reporting experience with consistent data accuracy
  • Use Case - A fire department that previously used a custom question "Was sprinkler system operational?" in their structure fire reports can disable this question due to new reporting requirements, and all previously authorized reports will continue to show the historical responses (Yes/No) for audit and analysis purposes. Meanwhile, if they create a new custom question "NFPA compliance verification completed?" for current reporting needs, this new question will only appear in incomplete reports requiring completion, ensuring authorized historical reports maintain their original data without confusing blank entries for newly added requirements.






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.





9. Adjustments in OFM Export File for Canadian Clients in NFIRS
  • What - The NFIRS export process for Canadian (OFM) clients has been enhanced to correctly populate the CM column with accurate kilometer values derived from place or dispatch coordinates, resolving calculation errors that were producing unrealistic distance values exceeding 1000 kilometers. The system now implements priority logic using place coordinates first, then dispatch coordinates as fallback, with validation to ensure realistic kilometer values in export files.
  • Why - This enhancement was implemented due to customer request to address miscalculated kilometer values in OFM export files where distance measurements were incorrectly showing extremely high values, impacting the accuracy of Canadian fire department reporting and compliance with OFM requirements.
  • How - Enhanced kilometer calculation is automatically applied during NFIRS export processing:
    • During NFIRS export, system evaluates coordinate availability for distance calculation
    • Place coordinates are used first when available for the incident location
    • If no place coordinates exist, system uses dispatch coordinates as fallback
    • Kilometer values are calculated using appropriate coordinate set and recorded in CM column
    • Validation logic ensures values remain within expected ranges, removing anomalies exceeding 1000 km
    • Note: Enhancement applies only to Canadian clients using NFIRS (OFM) reporting
    • Note: Previously affected reports have been validated and corrected in production
    • Note: System maintains consistent distance calculation methodology across all OFM exports
  • Use Case - A Canadian fire department's incident report showing a response from Station 12 to a residential fire will now display an accurate kilometer distance of 3.2 km in the CM column of their OFM export file, rather than the previously miscalculated value of 1,247 km that was occurring due to coordinate processing errors. This ensures their OFM reporting accurately reflects actual response distances for operational analysis and compliance reporting, enabling proper resource allocation planning and meeting provincial reporting requirements without data anomalies.



10. El Paso - Update Get Fire Incident Information API Payload for People Involved
  • What - The GET Fire Incident Report API has been enhanced with a new People Involved array in the payload, enabling capture of detailed information about individuals beyond response personnel involved in fire incidents. The enhancement includes comprehensive personal identifiers, demographics, and incident-related medical information for each person, providing complete incident participant reporting capabilities while maintaining backward compatibility with existing API consumers.
  • Why - This enhancement was implemented due to customer request from El Paso to improve fire incident reporting completeness and accuracy by capturing detailed information about all incident participants, not just response personnel, ensuring compliance with jurisdictional data requirements and comprehensive incident documentation.
  • How - The People Involved array is automatically included in API responses with comprehensive data structure:
    • Call GET Fire Incident Report API to receive enhanced payload with People Involved array
    • Each array element contains personal identifiers: Name Prefix, First Name, Middle Initial, Last Name, Name Suffix, Date of Birth
    • Demographics data includes Race and Gender information for each person
    • Incident-related medical information captures Body Site of Injury and Primary Apparent Symptom
    • Consumer applications can parse and display complete person details from the structured dataset
    • Note: Enhancement is backward-compatible and does not impact existing API consumers
    • Note: People Involved array is separate from existing Personnel reporting functionality
    • Note: All data points are structured for consistent parsing and integration
  • Use Case - When El Paso fire department responds to a residential fire with civilian injuries, the API now returns comprehensive information about affected residents including "Jane Doe, DOB 03/15/1985, Female, Hispanic, with smoke inhalation affecting respiratory system" in the People Involved array, separate from the Personnel array containing firefighter information. This enables their reporting systems to capture complete incident participant data for medical follow-up, insurance documentation, and comprehensive incident analysis while maintaining clear distinction between civilians and response personnel involved in the incident.



11. Ontario OFM Export Edits
  • What - The Ontario Export within the Fire Incident Module has been corrected to address mapping inconsistencies and validation issues affecting time fields, rescue counts, property loss values, and classification field alignment. The enhancement includes proper field sequencing for Area of Fire Origin through Item First Ignited, accurate time field mappings, and a new Canadian client validation rule for Item First Ignited to ensure compliance with Ontario reporting requirements.
  • Why - This enhancement was implemented due to customer request to resolve field misalignment issues in Ontario Export output where several fields were incorrectly mapped or positioned, particularly a field shift starting at Cause of Ignition that was causing incorrect data export and potential non-compliance with provincial reporting standards.
  • How - Enhanced export functionality automatically applies corrected mappings and validation:
    • Time field mappings for Call Hour/Min/Sec and Dispatch Hour/Min/Sec are confirmed and corrected
    • Number of People Rescued field properly links to backend system field for accurate export
    • Estimated Loss now maps directly to Property Loss field in Fire Incident
    • Classification fields export in correct sequence: Area of Fire Origin, Cause of Ignition, Heat Source, Type of Material First Ignited, Item First Ignited
    • Canadian client validation prevents saving Item First Ignited when incident types 111-118 have Object First Ignited values 10-19
    • Note: Corrections ensure proper field alignment without missing values in export sequence
    • Note: Validation logic maintains data integrity and compliance with provincial reporting standards
    • Note: Enhanced mappings apply automatically when generating Ontario Export files
  • Use Case - A Toronto fire department generating their monthly Ontario Export will now see accurate time stamps showing a structure fire call received at 14:32:15, dispatched at 14:33:22, with property loss of $125,000 correctly mapped to the Estimated Loss field, and classification fields like "Area of Fire Origin: Kitchen" and "Cause of Ignition: Electrical malfunction" appearing in proper sequence. The new validation will prevent data entry errors such as attempting to save "Item First Ignited: Cooking materials" when the Object First Ignited value conflicts with incident type rules, ensuring export files meet Ontario Fire Marshal reporting requirements.



12. Show the 1st Arriving Unit in the Pop out Info
  • What - The NFIRS form view has been enhanced to display First Arriving Apparatus information directly in the pop out info section, providing consistency with the Fire Documentation List View and enabling users to quickly reference the first arriving unit alongside unit codes. The enhancement includes real-time synchronization that reflects changes to apparatus assignments or time entries with formatting that matches existing unit code presentation.
  • Why - This enhancement was implemented due to customer request to provide consistency between the Fire Documentation List View and NFIRS form popout view, allowing users to access critical first arriving unit information without switching between different interface sections during incident documentation and review processes.
  • How - First Arriving Apparatus information is automatically displayed in enhanced popout interface:
    • Navigate to any NFIRS record and open the popout info section
    • First Arriving Unit appears below CAD Notes area, positioned next to Unit Codes
    • Information displays with Unit Code using same formatting style as other unit codes
    • Real-time updates automatically reflect changes to first arriving apparatus assignment or time entries
    • Cross-status availability ensures visibility across Not Started, Incomplete, and Authorized NFIRS records
    • Note: Updates occur dynamically when apparatus has no time assigned or first arriving apparatus is changed
    • Note: Format and placement align with existing Unit code formatting for consistent user experience
    • Note: Enhancement provides seamless reference point between Incident List and NFIRS form view
  • Use Case - A fire department supervisor reviewing a structure fire incident can now see "First Arriving Unit: Engine 12" directly in the NFIRS pop out alongside the unit codes, without needing to switch to the Fire Documentation List View or open the full incident record. If Engine 12's arrival time is later updated or if Engine 7 becomes the new first arriving unit due to timing adjustments, this information automatically updates in the pop out, ensuring supervisors always have current first arriving unit information readily available during incident review and quality assurance processes.




13. Increase the Length Allowed in Sq. Feet Field (NERIS)
  • What - The maximum input capacity for the square footage field in the Property Details section of the Information tab has been increased from 7 to 10 digits, enabling accurate reporting of very large buildings up to 9,999,999,999 square feet. This enhancement ensures incident reports can capture correct property details for large commercial, industrial, and institutional facilities without data truncation limitations.
  • Why - This enhancement was implemented due to customer request to address input limitations that prevented accurate square footage entry for very large buildings, where facilities exceeding 10 million square feet could not be properly documented due to the previous 7-digit field restriction.
  • How - Enhanced square footage input is automatically available in Property Details:
    • Navigate to Information tab in an Incident Report
    • Open Property Details section
    • Enter square footage in the Sq. Feet field with up to 10 digits capacity
    • Field now supports accurate input for buildings up to 9,999,999,999 sq. ft.
    • Note: Enhancement ensures incident reports reflect correct property details for all building sizes
    • Note: Previous 7-digit limitation has been removed to accommodate large facilities
    • Note: Field accepts standard numeric input without special formatting requirements
  • Use Case - A fire department responding to an incident at a large manufacturing complex with 14,944,455 square feet can now accurately enter the complete square footage in their incident report, ensuring proper documentation for insurance purposes and operational planning. Previously, this facility's size would have been truncated, potentially affecting resource allocation calculations and compliance reporting that rely on accurate property size information for risk assessment and response planning.




14. Improve Apparatus Card to Show Only Available EMS Date/Times
  • What - The Apparatus card has been enhanced to display only EMS times that users can actually enter, eliminating confusion by dynamically showing only editable fields based on EMS module activation and condition fulfillment. The system now intelligently evaluates EMS conditions and renders only user-accessible time fields, removing non-editable EMS fields that previously appeared regardless of editability status.
  • Why - This enhancement was implemented due to customer request to resolve user confusion caused by EMS-related time fields appearing on the Apparatus card even when users could not manually enter corresponding times, creating misleading interface elements that suggested functionality was available when EMS conditions were not active.
  • How - Enhanced Apparatus card display is automatically managed through intelligent field evaluation:
    • System evaluates EMS Module status and related EMS conditions before rendering fields
    • User-editable EMS times appear on Apparatus card when conditions are met
    • Non-editable EMS times are automatically hidden to prevent misleading information
    • Fields like "Patient Left Scene" and "Patient Arrive at Destination" display only when editable
    • Manual entry capability continues for active, editable EMS conditions including "Apparatus Arrived Patient" and "Apparatus Transfer of Care"
    • Note: Dynamic display prevents confusion by showing only accessible functionality
    • Note: Enhancement supports both manual entry and EMS module-specific conditions when active
    • Note: Interface maintains consistency by removing inaccessible field references
  • Use Case - A fire department using the system without the EMS module activated will no longer see confusing time fields like "Patient Transfer of Care" or "Apparatus Arrived Patient" on their Apparatus card, eliminating the confusion that previously occurred when these fields appeared but couldn't be edited. For departments with active EMS modules responding to medical calls, these same fields will appear and function normally, allowing proper documentation of patient care timeline events while maintaining a clean interface that only shows relevant, actionable fields.




15. Adding User to Apparatus Personnel Removes Them from Station Response
  • What - The system now provides warning messages when personnel are documented in both Station Response and on an Apparatus for the same incident, preventing duplicate personnel documentation through enhanced validation checks. The enhancement includes improved tooltip guidance for apparatus assignment settings and configurable override capabilities that allow departments to maintain intentional duplication when operationally necessary while alerting users to potential documentation conflicts.
  • Why - This enhancement was implemented due to customer request to prevent duplicate personnel documentation that can occur when the same individual is listed in both Station Response and Apparatus assignments, ensuring accurate personnel tracking and eliminating confusion in incident reporting and resource management.
  • How - Duplicate personnel detection is automatically managed through enhanced validation processes:
    • When adding personnel to an Apparatus, system checks Station Response grid for the same individual
    • If duplicates are found, warning message displays: "Warning: Personnel is listed on both Station Response and on an Apparatus. This will cause duplicate documentation of personnel"
    • Users can click OK to acknowledge the warning and proceed with assignment
    • Apparatus Assignment Override setting in Fire Incident Setup → Response → Resources controls duplication behavior
    • Override enabled: Personnel can exist in both Apparatus and Station Response
    • Override disabled: Personnel cannot be duplicated across assignments
    • Enhanced tooltip provides clarity: "This will impact both Apparatus and Station Response"
    • Note: Departments with intentional duplication workflows can bypass warnings via override setting
    • Note: System maintains personnel tracking accuracy while providing operational flexibility
  • Use Case - When a fire captain is already listed in the Station Response as "Responding" and a dispatcher attempts to add the same captain to Engine 7's apparatus roster, the system displays a duplicate warning message, preventing accidental double-documentation that could inflate personnel counts in incident reports. If the department intentionally assigns personnel to both station response and apparatus roles for operational tracking purposes, they can enable the Apparatus Assignment Override setting to allow this duplication while maintaining awareness of the documentation impact through the warning system.







    • Related Articles

    • 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 ...

    • ePCR Release Notes: July 2025

      Video <br> New Features 1. AI-Powered Attachment Data Extraction in ePCR This feature introduces AI-powered image analysis within the ePCR attachment modal, allowing users to automatically extract structured patient data (e.g., name, DOB, ...

    • Mobile App: Release Notes (May 2025)

      In order to provide you with more detailed information on our updates we have broken the Release Notes down by module. Video Current iOS Version 5.8.4 Current Android Version 6.9.4 New Features (iOS) Fire Investigations Menu Integration What: Fire ...

    • 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 ...

    • Release Notes - Fire Investigations

      In order to provide you with more detailed information on our updates we have broken the Release Notes down by module. Video New Features 1. Support attaching audio files. What: Added support for attaching audio files (MP3) to Fire Investigation ...