1. AI for NFIRS Canada

• What - Artificial intelligence capabilities have been introduced specifically for Canadian clients following the NFIRS (National Fire Incident Reporting System) standard, leveraging Deepgram and Bedrock endpoints configured for Canadian regions to enable seamless analysis, transcription, and integration of narrative data within NFIRS reports. The system provides AI-powered narrative analysis with real-time processing, editable transcriptions, voice recording functionality, and automatic data mapping to official report fields while ensuring compliance and performance through Canadian-specific regional configurations.
• Why - This enhancement was implemented due to customer request to provide Canadian fire departments with AI-powered incident reporting capabilities that comply with regional requirements, enabling faster and more accurate narrative documentation through voice transcription and intelligent field mapping while maintaining data sovereignty through Canadian-hosted AI endpoints.
• How - AI functionality is accessed through enhanced NFIRS Canada reporting interface with comprehensive voice and data processing:
  • Click Analyze button to initiate AI analysis through Deepgram (speech-to-text) and Bedrock (AI model) endpoints in Canadian regions
  • AI interface displays analyzed narratives with multiple narratives merged correctly for accurate analysis
  • Edit or delete transcribed content directly from AI interface for accuracy refinement
  • Click Apply button to automatically map AI-generated data into NFIRS report fields
  • Use Record button to start voice recording for data input capture
  • Use Stop button to halt recording and save session securely
  • Note: AI integration specifically designed for Canadian NFIRS clients with regional compliance
  • Note: System correctly handles AI data display, transcription, and field mapping within reports
  • Note: All user interactions (Analyze, Apply, Record, Stop) operate with real-time processing
• Use Case - A Canadian fire captain responding to a structure fire can use the Record button to verbally document the incident while still on scene, describing "Two-story residential structure with heavy smoke showing from second floor windows, primary search completed with negative results, fire contained to bedroom of origin using interior attack." The AI system processes this narrative through Canadian-region Deepgram and Bedrock endpoints, transcribes the audio, analyzes the content, and when the captain clicks Apply, automatically populates relevant NFIRS report fields including incident type, actions taken, and property information while maintaining the complete narrative text for review and editing, significantly reducing documentation time and improving accuracy compared to manual data entry.
  

2. Add Editable Distance (Kilometers) Field in Location Section for Canadian Clients

• What - A new editable "Distance (Kilometers)" field has been added to the Location section of tasks for Canadian clients, replacing the existing custom Distance field with a standardized hardcoded field that allows users to view, edit, and manage distance values directly in the user interface. The enhancement includes automatic data migration from the legacy custom field, workflow-controlled visibility configuration, and export accuracy improvements to ensure incident exports reflect the most up-to-date distance information.
• Why - This enhancement was implemented due to customer request to provide Canadian clients, particularly those using Ontario Fire Marshal (OFM) NFIRS exports, with the ability to manually correct system-calculated distance values when inaccurate, ensuring export data accurately reflects actual incident locations while maintaining workflow flexibility for field requirement configuration across different provinces.
• How - The Distance field is automatically integrated into the Location section with enhanced editability and configuration:
  • System automatically calculates Distance (Kilometers) when incident is created
  • Distance field displays in Location section of task details with visibility controlled by workflow configurations
  • Users can edit the Distance value directly if calculated result is incorrect
  • Updated values save and reflect in incident export files for accurate reporting
  • Workflow configurations determine whether field is mandatory or optional for specific clients or regions
  • Data migration automatically preserves and maps all existing Distance data from legacy custom field to new standardized field
  • Ontario (OFM using NFIRS) clients see visible and editable field for export accuracy
  • Note: Non-Ontario clients have field hidden by workflow definition and excluded from exports
  • Note: Administrators configure field requirement through workflows or provincial workflows, not hardcoded
  • Note: System supports mapping Distance values from occupancy data, CAD data, or other predefined sources
• Use Case - An Ontario fire department responding to a rural structure fire sees the system automatically calculate 12.7 kilometers from station to incident location, but the fire chief knows from GPS navigation that the actual distance was 14.2 kilometers due to detours around road construction. The chief can edit the Distance field directly in the Location section to reflect the accurate 14.2 km value, ensuring their OFM NFIRS export contains correct distance data for response analysis and provincial reporting requirements, while departments in other provinces using different reporting standards have the field hidden automatically through workflow configuration without affecting their incident documentation.
  

3. Update Workflows to Account for Grids

• What - Workflow condition capabilities have been expanded to interact directly with grid data through new counting operators added to the Condition dropdown, enabling workflows to count total records or records meeting specific criteria within grids. The enhancement includes group condition support for advanced logical configurations, Error Workflow integration that accurately counts and displays errors across grid fields and tabs, and comprehensive execution logic that applies count-based evaluations to trigger actions when thresholds or conditions are met across multiple grid types including Aiding Apparatus, Station Response, Vehicles, Equipment, and Payroll Summary.
• Why - This enhancement was implemented due to customer request to enable more complex logic and automation capabilities by allowing workflows to evaluate conditions directly on grid data, supporting count-based validation rules and error tracking that were previously unavailable for grid components in the workflow system.
• How - Grid-based workflow conditions are configured through enhanced workflow definition setup with counting operators:
  • Configure workflow conditions that interact with grids to access new counting operators in Condition dropdown
  • Specify integer parameter to define count threshold for total records or records meeting specific criteria
  • Create group conditions to combine multiple logical statements for advanced configurations
  • Workflow execution evaluates grid data according to defined conditions and applies count-based logic
  • Actions trigger when thresholds or conditions are met during workflow processing
  • Error Workflows execute across all impacted grids with accurate error counting per tab
  • Error results display correctly in People Involved and Payroll Summary areas
  • Note: Feature expands workflow capabilities to include count-based logic for grid components
  • Note: Group condition support ensures accurate and flexible logical grouping
  • Note: Impacted grids include Aiding Apparatus, Station Response, Vehicles, Equipment, and Payroll Summary
• Use Case - A fire department can now create a workflow that validates "Total number of personnel in Station Response grid must be greater than or equal to 2" to ensure minimum staffing requirements are met before authorizing incident reports. If only one firefighter is documented in the Station Response grid, the Error Workflow triggers a validation error displaying "Minimum staffing requirement not met - at least 2 personnel required" in the People Involved section, preventing report authorization until additional personnel are added. This count-based grid validation ensures compliance with departmental policies and NFIRS reporting standards without requiring manual verification of staffing levels across multiple incident reports.
  

4. Move NERIS Dropdown and Entity ID Configuration to Client-Facing Fire Incident Setup

• What - NERIS configuration has been migrated from the SuperAdmin panel to the Client UI Setup area, enabling departments to independently manage their transition from NFIRS to NERIS with streamlined department-level control. The enhancement includes one-way transition confirmation, Entity ID activation warnings, API permission verification through a "Check Permissions" button, real-time connection checks, and comprehensive setup workflow enhancements with automatic status updates, error indicators, and completion tracking across all NERIS setup steps.
• Why - This enhancement was implemented due to customer request to provide departments with direct control over their NFIRS to NERIS transition process, ensuring a more transparent and guided setup experience while eliminating dependency on SuperAdmin intervention for configuration management and enabling agencies to manage their own timeline for NERIS activation.
• How - NERIS configuration is managed through enhanced Client UI Setup with comprehensive validation and guidance:
  • Navigate to Setup section in client UI and change dropdown from NFIRS to NERIS
  • One-way transition confirmation popup reminds users this is permanent decision requiring acknowledgment
  • Entity ID field displays prominent warning: "Entering your agency's Entity ID will activate the connection to NERIS and your agency will start sending live data to NERIS immediately. Please enter your Entity ID only when you are ready to start utilizing NERIS as your sole system of record for incidents"
  • Click "Check Permissions" button to verify agency's access to NERIS API
  • 403 error response guides users to documentation for re-enrollment and credential acquisition
  • Successful verification updates API status to "Successfully Connected"
  • Setup workflow enhancements provide automatic status updates, "Attention Required" indicators for errors, direct navigation to specific unit/station pages, and completion tracking
  • Note: Both TEST and PROD environments follow same configuration flow for consistency
  • Note: NERIS tab remains hidden until transition setup is activated
  • Note: Visual warnings prevent accidental activation of live data transmission
• Use Case - A fire department preparing to transition from NFIRS to NERIS can now manage the entire configuration process directly in their Setup area without requiring SuperAdmin assistance. The fire chief reviews the one-way transition warning, confirms their department is ready to switch, then enters their Entity ID only after verifying their stations and units are properly configured. When they click "Check Permissions," the system validates their NERIS API access and confirms "Successfully Connected," allowing them to complete the remaining setup steps including station registration and unit configuration. If any errors appear with "Attention Required" status, they can navigate directly to the specific station or unit page to resolve issues before activating live NERIS data transmission, maintaining full control over their transition timeline and ensuring data integrity.
  

5. Create NERIS Readiness Check

• What - A comprehensive NERIS Readiness Check has been introduced to ensure departments meet all critical data requirements before transitioning from NFIRS to NERIS, featuring automated validation for station address accuracy, apparatus-to-station associations, and NFIRS incident submission status. The system provides interactive error resolution links directing users to specific records requiring correction, iterative checking capabilities allowing unlimited validation reruns until issues are resolved, and locks the Entity ID input field and NFIRS/NERIS dropdown until all readiness checks pass successfully, proactively preventing registration errors and enhancing transition efficiency.
• Why - This enhancement was implemented due to customer request to reduce NERIS registration errors and support overhead by ensuring departments have complete and correct configurations before transitioning, addressing issues where incomplete station addresses, unassociated apparatus units, or pending NFIRS incidents caused complications during the NERIS activation process.
• How - NERIS Readiness validation is managed through automated checking with interactive error resolution:
  • Navigate to Fire Incident Setup → NERIS and click NERIS Readiness Check button
  • System executes backend validation script checking three critical conditions: Station address completeness (number, street, city, state, zip), Unit-to-station associations, and Pending NFIRS incidents
  • Error report displays with direct links to specific records requiring correction: invalid station addresses link to Station records, unassociated units link to Unit records, unsubmitted incidents open for completion
  • Rerun check after fixing errors as many times as needed until all validations pass
  • Success confirmation displays message about mutual aid Entity ID requirements and unlocks NERIS Entity ID field and NFIRS/NERIS dropdown for transition
  • Note: Readiness Check accessible only in Production environment, not Test environment
  • Note: Users cannot enable NERIS or modify dropdown until all checks pass without error
  • Note: Feature ensures departments meet readiness criteria before switching to minimize configuration issues
• Use Case - A fire department preparing to activate NERIS runs the Readiness Check and discovers three issues: Station 5 is missing a complete street address, Ladder 3 isn't associated with any station, and five incidents from last month haven't been submitted to NFIRS yet. The system provides direct links to each problem - clicking the Station 5 error opens that station's record to add the missing address, the Ladder 3 link opens the apparatus record to assign it to Station 3, and each incident link opens the pending reports for NFIRS submission. After resolving all issues and rerunning the check, the success message appears confirming readiness, unlocking the Entity ID field so they can complete their NERIS transition with confidence that all prerequisite data requirements are properly configured.
  

6. Migrating to NERIS - Step 1

• What - A new "Looking to switch to NERIS" section has been introduced to enable departments and agencies to create and manage their enrollment integrations for both TEST and PROD environments, providing key resources and links for manual NERIS integration completion. The section is accessible only to NFIRS users with the special "migrating to NERIS" permission and includes three essential links: NERIS Transition Checklist with FirstDue Client ID and step-by-step enrollment instructions, NERIS PROD ID lookup page, and NERIS official login portal.
• Why - This enhancement was implemented due to customer request to provide departments transitioning from NFIRS to NERIS with centralized access to enrollment resources and guidance, ensuring users have the necessary tools and documentation to complete their NERIS integration setup independently for both testing and production environments.
• How - NERIS transition resources are accessed through permission-controlled section with comprehensive guidance links:
  • Section "Looking to switch to NERIS" appears only for NFIRS users with "migrating to NERIS" permission
  • Three resource links provide enrollment guidance and access:
  • NERIS Transition Checklist opens KB article in new tab with FirstDue Client ID and step-by-step enrollment instructions
  • How To Obtain your NERIS PROD ID opens NERIS search page in new tab to find department and obtain NERIS ID
  • NERIS Official Link opens NERIS main login page in new tab for direct system access
  • Users follow provided instructions to complete enrollment manually for TEST or PROD environments
  • Note: Section visibility restricted to ensure only authorized users access NERIS transition resources
  • Note: KB articles and NERIS links maintained for accuracy and current information
  • Note: System checks user permissions before displaying section on NFIRS interface
• Use Case - A fire department administrator planning to transition from NFIRS to NERIS can access the "Looking to switch to NERIS" section after receiving the migrating to NERIS permission, where they find the Transition Checklist containing their FirstDue Client ID and detailed enrollment steps. They click "How To Obtain your NERIS PROD ID" to search for their department in the NERIS system and retrieve their official Entity ID, then use the NERIS Official Link to log into the NERIS portal and verify their enrollment status. These centralized resources guide them through the manual enrollment process for both their TEST environment setup and eventual PROD environment activation, ensuring they have all necessary credentials and documentation before beginning their full NERIS transition.
  

---

1. Support Both .xlsx and .csv File Types in Incident Report Import Wizard

• What - The Incident Report Import Wizard now supports both .xlsx and .csv file formats, along with legacy .xls files, enabling users to directly upload Excel templates with validations, dropdowns, and rules without manual conversion. The system maintains backward compatibility for existing CSV workflows while implementing consistent validation rules across all supported formats, reading data from the first tab of Excel files and providing clear error messages for unsupported file types.
• Why - This enhancement was implemented due to customer request to streamline the import process by eliminating the need to manually convert Excel templates into CSV files, allowing fire departments to use their preferred Excel-based templates with built-in validations and dropdown lists directly in the import workflow.
• How - Enhanced file format support is automatically available in the Import Wizard interface:
  • Upload files in Import Wizard using supported types: .xlsx, .csv, or .xls
  • System validation checks file format and proceeds with parsing for valid types
  • Unsupported file types (e.g., .ods, .json) display error message: "Only .xlsx, .xls, and .csv file types are supported"
  • Excel file parsing reads data from first tab only for .xlsx and .xls formats
  • CSV processing continues using existing workflow without changes
  • Consistent validation enforces same structure, column requirements, and rules across all supported formats
  • Import completion proceeds successfully or displays precise error messages when validation fails
  • Note: Backward compatibility ensures existing CSV workflows remain unchanged
  • Note: Excel templates with validations, dropdowns, and rules can be used directly without conversion
  • Note: Error handling provides clear guidance when unsupported file formats are attempted
• Use Case - A fire department using a standardized Excel template with dropdown lists for incident types, validation rules for dates and times, and formatted columns for apparatus information can now upload their .xlsx file directly to the Import Wizard without converting to CSV format. The system reads the incident data from the first tab of their Excel workbook, applies the same validation rules that would apply to CSV files, and completes the import process, eliminating the manual conversion step that previously required removing Excel formatting and saving as CSV before uploading to the system.
  

2. Support Both .xlsx and .csv File Types in Aiding Department Import Wizard

• What - The Aiding Department Import Wizard now supports both .xlsx and .csv file formats for all core imports, enabling users to directly upload Excel templates with built-in validations, dropdowns, and rules without manual conversion. The system maintains backward compatibility for existing CSV workflows while parsing Excel data from the first tab of workbooks and providing clear error handling for unsupported file types.
• Why - This enhancement was implemented due to customer request to streamline the aiding department import process by eliminating the need to manually convert Excel templates into CSV files, allowing fire departments to use their preferred Excel-based templates with built-in validations directly in the import workflow.
• How - Enhanced file format support is automatically available in the Aiding Department Import Wizard:
  • Navigate to Aiding Department Import Wizard and select Upload File
  • Choose either .xlsx (Excel template) or .csv file for upload
  • Valid .xlsx files are automatically parsed with data imported from first tab of workbook
  • Valid .csv files are processed using existing workflow without changes
  • Unsupported file types (e.g., .xls, .ods, .json) display error message: "Unsupported file type. Please upload a .xlsx or .csv file"
  • Excel template functionality preserved including validations, dropdowns, and rules during import
  • Note: Backward compatibility ensures existing CSV import workflows remain unchanged
  • Note: Parsing for Excel files limited to first tab to maintain consistency
  • Note: Error handling provides clear guidance when unsupported formats are attempted
• Use Case - A fire department coordinating mutual aid responses can now upload their standardized Excel template containing aiding department information with dropdown lists for department names, validation rules for contact information, and formatted columns for response capabilities directly to the Import Wizard. The system reads the aiding department data from the first tab of their Excel workbook, applies appropriate validation rules, and completes the import process without requiring manual conversion to CSV format, eliminating the time-consuming step of removing Excel formatting before uploading mutual aid coordination data.
  

3. Improve Search over Dispatch Incident Type Column in NFIRS Notification Table

• What - Search performance for the Dispatch Incident Type column in the nfirs_notification table has been optimized through indexing techniques, significantly reducing query execution time and improving overall system responsiveness. The enhancement applies targeted optimization to the dispatch_incident_type column, delivering faster data retrieval during incident type lookups while maintaining data accuracy and integrity without requiring schema changes for consuming applications.
• Why - This enhancement was implemented due to customer request to improve efficiency for both ad-hoc queries and system-level searches involving dispatch incident type, reducing load times in reports and dashboards to provide more responsive user experiences when filtering or analyzing incident data by dispatch type.
• How - Search optimization is automatically applied through enhanced database indexing:
  • Indexing optimization applied to dispatch incident type column in nfirs_notification table
  • Faster data retrieval occurs automatically when users perform lookups or filters on this field
  • Optimized structure leveraged by system for faster access during incident type searches
  • Reduced load times evident in reports, dashboards, and workflows relying on dispatch incident type filter
  • No user intervention required as improvements apply automatically
  • Note: No schema changes required for consuming applications
  • Note: Data accuracy and integrity preserved with results remaining consistent with pre-optimization behavior
  • Note: Enhancement improves efficiency for both ad-hoc queries and system-level searches
• Use Case - A fire department analyst generating monthly reports filtering incidents by dispatch type such as "Structure Fire" or "Medical Emergency" will experience significantly faster query execution and report generation times. Previously, searching across thousands of incidents to filter by specific dispatch types could take several seconds, but with the optimized indexing, these searches now return results nearly instantaneously, allowing analysts to generate comprehensive incident type reports and dashboards more efficiently while maintaining the same accurate data results they relied on before the optimization.
  

4. Validation FDID/NERIS ENTITY ID Associated for Aiding Departments

• What - Real-time validation has been introduced for Aiding Departments to ensure each department has an associated FDID (for NFIRS) or Entity ID (for NERIS), preventing incomplete or inaccurate reporting through visual error indicators, real-time error messaging, and section-level error counts. The system highlights missing ID fields with red outlines and exclamation icons, displays validation messages, and flags incomplete configurations while still allowing incremental setup saves, ensuring data accuracy and compliance with NFIRS and NERIS reporting standards.
• Why - This enhancement was implemented due to customer request to prevent incomplete or inaccurate reporting that occurs when Aiding Departments lack required identification numbers, addressing the issue where missing IDs result in incomplete records affecting statistics, metrics, and potential grant funding tied to accurate mutual aid reporting.
• How - Validation functionality provides real-time feedback through enhanced Setup UI indicators:
  • In Aiding Department Setup UI, missing FDID (NFIRS) or Entity ID (NERIS) fields are outlined in red with exclamation icon
  • Hover over exclamation icon displays validation message: "Department is missing an associated ID"
  • Real-time feedback appears immediately after data entry or selection before saving
  • Incremental saves allowed - users can save departments without IDs for later correction
  • Saved records with missing IDs are visually flagged within grid similar to incomplete vitals rows
  • Error count badge appears in Aiding Department section header summarizing number of missing IDs
  • Departments without IDs are excluded from NFIRS/NERIS submissions to prevent inaccurate data transmission
  • Note: Validation follows similar pattern to existing PCR-style error indicators for consistency
  • Note: System supports NFIRS to NERIS transition by identifying departments missing NERIS Entity IDs
  • Note: Visual flagging helps administrators locate and fix incomplete configurations efficiently
• Use Case - A fire department administrator adding mutual aid partners to their system will see immediate red outline validation when they create "County Fire Department" without entering the FDID, with the exclamation icon displaying "Department is missing an associated ID" when hovered. The administrator can save the incomplete record to continue setup work, and the Aiding Department section shows an error count badge indicating "3 departments missing IDs" to track progress. When generating NFIRS reports, departments without proper IDs are automatically excluded from submission, preventing data quality issues that could affect grant funding or compliance reporting while giving administrators clear visibility into which records need completion.
  

5. OIC Logic Change from Clear Time to Dispatch Time

• What - The OIC (Officer In Charge) determination logic has been updated to use dispatch time instead of clear time for incidents where no apparatus arrives on scene, improving accuracy when units are dispatched but cancelled or never arrive. The enhanced logic integrates with the "Disable OIC based on First Arriving Unit" configuration setting while preventing false data population in the "1st Arriving Unit" field and operating seamlessly during the incident not-started stage using CAD data.
• Why - This enhancement was implemented due to customer request to improve OIC determination accuracy for incidents where all dispatched units are cancelled or never arrive on scene, addressing issues where the previous clear time logic did not appropriately identify the officer in charge when arrival times were unavailable.
• How - OIC determination logic is automatically applied based on arrival time availability and configuration settings:
  • During incident creation in not-started state, CAD data provides dispatch information for assigned units
  • When no "Arrive Scene Time" exists for any unit, system uses first unit's dispatch time to determine OIC
  • When units do arrive, traditional first arriving unit logic applies as expected
  • "Disable OIC based on First Arriving Unit" setting checked leaves OIC field blank regardless of dispatch times
  • Setting unchecked with no arrivals uses first dispatch time to determine OIC without populating "First Arriving Unit" field
  • "1st Arriving Unit" field on Fire Incident List remains empty when no units arrive on scene
  • Note: Update modifies logic from previous implementation that used lowest clear time
  • Note: Configuration setting controls whether OIC population occurs based on dispatch data
  • Note: Seamless CAD integration provides real-time data handling before incident is started
• Use Case - When multiple units are dispatched to a reported structure fire at 14:30 but all are cancelled en route at 14:35 after confirmation of a false alarm with no units arriving on scene, the system now uses the first dispatch time (14:30) to determine the OIC rather than the clear time (14:35), ensuring the officer from the first dispatched unit is properly identified as responsible for the incident. The "1st Arriving Unit" field remains blank since no units actually arrived, preventing misleading data in the Fire Incident List while maintaining accurate officer in charge documentation for administrative and reporting purposes.
  

6. Create WebSocket to Block/Unblock Actions Around Read Only Capability

• What - A WebSocket-based mechanism has been introduced to manage real-time blocking and unblocking of user actions when accessing incident reports, enabling users to view reports in read-only mode while another user is actively editing. The enhancement provides dynamic state management through WebSocket integration that immediately updates all connected clients, replacing the previous complete lockout behavior with collaborative access that maintains data integrity while improving visibility and workflow efficiency.
• Why - This enhancement was implemented due to customer request to improve collaboration and visibility by allowing multiple users to access incident reports simultaneously, addressing the previous limitation where reports were entirely locked during editing, preventing other users from viewing critical incident information and creating workflow bottlenecks.
• How - Real-time read-only access is managed through WebSocket communication with automatic state updates:
  • User A opens incident report for editing, triggering system to send WebSocket "block" event to all other clients
  • Other users (User B, etc.) receive block event and are automatically placed in read-only mode with full report visibility but no modification capability
  • Read-only users can view all report data including apparatus details and incident information without risk of data conflicts
  • User A closes or saves the report, triggering system to send WebSocket "unblock" event to all connected clients
  • All connected clients update state in real time, allowing editing access to next user as needed
  • Consistent behavior mirrors existing mechanism used for Pending Authorized/Authorized reports
  • Note: WebSocket integration enables immediate state updates across sessions without page refresh
  • Note: Enhancement eliminates previous complete lockout that prevented viewing during editing
  • Note: Multiple users can access reports simultaneously while maintaining data integrity
• Use Case - When a fire captain is actively editing an incident report to add narrative details and update apparatus information, a battalion chief who needs to review the incident for operational decisions can now open the same report in read-only mode to view all current information including response times, personnel assigned, and actions taken without waiting for the captain to complete their edits. Once the captain saves and closes the report, the WebSocket automatically updates the battalion chief's view to allow editing if needed, eliminating the previous workflow bottleneck where supervisors were completely locked out from viewing critical incident information during the documentation process.
  

7. Map Dispatch Location in Header to Location Address in Form vs CAD Data

• What - Enhanced logic has been introduced to automatically populate the Dispatch Location in the header when users manually enter incident addresses, extending the functionality that previously only worked for CAD-originated incidents. The system now correctly maps and maintains both Incident Location and Dispatch Location fields during manual entry, with smart update logic that respects the "Is incident location different from dispatch location" toggle setting while synchronizing address, city, state, and zip code fields between form and header.
• Why - This enhancement was implemented due to customer request to ensure Dispatch Location fields populate correctly for manually created incidents, addressing the limitation where this field only populated when incidents originated from CAD, creating inconsistencies in location documentation for departments that manually enter incident information.
• How - Location field mapping is automatically managed through enhanced logic for manual entries:
  • When users manually enter address information in Location fields, both Incident Location and Dispatch Location in header update automatically
  • With toggle "Is incident location different from dispatch location" = OFF, system mirrors all address updates to both fields
  • With toggle = ON, address updates only affect Incident Location while Dispatch Location retains originally entered address
  • Field-level mapping synchronizes address, city, state, and zip code between form and header
  • CAD-generated incidents continue populating Dispatch Location automatically with no behavior changes
  • Enhancement applies to all forms: Canada, NFIRS, and NERIS for universal consistency
  • Note: Logic change only impacts manually created incidents or incidents without CAD integration
  • Note: Smart toggle logic ensures accurate record of dispatch origin when incident and dispatch locations differ
  • Note: Seamless CAD integration compatibility maintains existing behavior for CAD-originated calls
• Use Case - A fire department dispatcher manually creating an incident record for a structure fire at 456 Oak Street enters the address in the Location fields, and the system automatically populates both Incident Location and Dispatch Location in the header with "456 Oak Street, Springfield, IL 62701." If the later actual fire location is the rear building at 456-B Oak Street and enables the "Is incident location different from dispatch location" toggle, they can update the incident address to 456-B without changing the Dispatch Location, which correctly preserves the original dispatch address of 456 Oak Street for accurate response documentation and ensuring dispatch records reflect where units were originally sent versus where they ultimately responded.
  

8. Populate "Riding Position" from CrewSense Integration

• What - The system now automatically populates the Riding Position field using data from the CrewSense integration, mapping the position_job column directly to ensure personnel riding positions are accurately reflected within Apparatus details. The enhancement provides case-sensitive matching for data accuracy, system-wide visibility across apparatus lists and incident views, and seamless integration through CAD Refresh processes while maintaining existing configurations when CrewSense data is unavailable.
• Why - This enhancement was implemented due to customer request to eliminate manual entry of riding positions and ensure consistent personnel assignment documentation across incidents by leveraging existing CrewSense scheduling data, improving data accuracy and reducing administrative workload for apparatus staffing documentation.
• How - Riding Position population is automatically managed through CrewSense integration with case-sensitive data mapping:
  • System retrieves CrewSense data for each personnel during synchronization or CAD Refresh events
  • position_job value from CrewSense is mapped directly to Riding Position field in Apparatus details
  • Case-sensitive matching ensures data accuracy and consistency with CrewSense configuration
  • Populated riding positions display in Apparatus list, individual incidents, and through CAD Refresh updates
  • When CrewSense provides no position_job data, Riding Position remains as previously configured
  • Note: Automatic mapping occurs during synchronization events without manual input required
  • Note: Values must match exactly between systems due to case-sensitive mapping requirements
  • Note: System-wide visibility ensures consistent riding position data across all incident documentation
• Use Case - When CrewSense shows Captain Johnson assigned as "Officer" and Firefighter Smith as "Driver" for Engine 7's shift, this information automatically populates into the Riding Position field when incidents are created or when CAD Refresh updates occur, eliminating the need for dispatchers or officers to manually enter riding assignments for each incident. If Engine 7 responds to multiple calls during the shift, the riding positions remain consistently documented across all incidents without repetitive data entry, ensuring accurate personnel assignment records for operational analysis and NFIRS reporting while reducing documentation time and potential entry errors.