Video

---

New Features

1. Introduce a retry strategy for handling failures in data export to NERIS, covering both API transmission issues and database persistence errors.
   

• When a data export to NERIS fails (either during API transmission or DB persistence), the system logs the failure and schedules a retry based on configurable settings.
• A new section in Fire Incident Setup will list failed attempts for Stations and Units, allowing users to manually trigger a retry.
• Incidents will not have a manual retry option, but the system will automatically update their status based on the type of error.
• Retry parameters (number of attempts, delay between retries) can be adjusted via system settings.
• The system will log final failure status after exhausting all retries, to support troubleshooting and follow-up actions.
  

Retry Strategy for API Consumption (Exponential Backoff + Jitter)

To handle temporary failures when consuming an API, a retry strategy combining the following was implemented:

1. Exponential Backoff: Progressively increases wait times between retries (e.g., 10s, 15s, 20s), reducing API load and allowing recovery.
2. Jitter: Adds randomness (±0.5s) to retry intervals, preventing the thundering herd effect in distributed systems.
3. Retry Limit: By default, a maximum of 3 retry attempts before marking the process as failed.

Error Classification & Handling

Errors are categorized into 4 types, each with specific handling:

Note: Errors that cannot be processed (with or without retries) are stored in the database for client review.

Error Visibility & Management

Errors can be viewed in:

• Fire Incident Setup → Neris → Neris Export List
  • Neris clients (previously admins-only) can now:
    • Manually retry Stations and Units from the list.
    • View failure details (e.g., validation errors, exhausted retries).
      

Error Handling Workflow

Case 1: Incident Export Failure

• Validation Failed:
  • No retries. Status → Incomplete.
  • Client must correct and reauthorize submission.
• Retries Exhausted:
  • Status → Pending Authorization.
  • No automatic retries from the list.

Case 2: Station/Unit Export Failure

• Validation Failed or Retries Exhausted:
  • Logged in DB for manual client review.

2. Workflows -  Add Conditional Logic for Time-Based Fields

1. Enables advanced time-based conditional logic within Workflows, similar to existing functionality in ePCR.
   

How it works:

You can now configure Workflows with the following new conditional options for Date/Time fields:

• Greater Than Constant Datetime Between Fields
• Greater Or Equal Than Constant Datetime Between the Field and the Current Time
• Greater Or Equal Than Constant Datetime Between Fields
• Less Than Constant Datetime Between Fields
• Less Or Equal Than Constant Datetime Between Fields
• Less Or Equal Than Constant Datetime Between the Field and the Current Time

These conditions can be applied when defining workflow rules, enabling more granular control over when actions are triggered based on time intervals.

3. Workflows - Add parameter for Times

1. Introduced support for a new workflow parameter that allows referencing only the Time portion of a DateTime (dttm) field, without requiring the full Date and Time input.
   

How it works:

1. A new configuration option is introduced within the workflow parameter setup UI.
2. When defining a workflow, users can select to reference only the Time component of a dttm field.
3. If the Time-only option is used, the system ignores the Date component when evaluating the condition.
4. This allows for cleaner, more targeted logic in workflows that are time-sensitive but not date-dependent.
5. For workflows requiring both Date and Time, the existing parameter setup remains unchanged.

4. OIC Logic 

1. Enhances the Officer In Charge (OIC) workflow to support scenarios where no department apparatus records an "arrive on scene" time, ensuring accurate OIC assignment.
   

How it works:

1. When enabled via settings, the system checks for scenarios where no apparatus has logged an "arrive on scene" time.
2. If at least one apparatus has a "cleared time" but none have an "arrive on scene" time, the system uses the earliest cleared time to determine the OIC based on the established hierarchy.
3. If an "arrive on scene" time is later recorded for any apparatus, the OIC is re-evaluated and updated accordingly.

5. Ensure Accurate Printing of All NERIS Fields

1. Enhance the print functionality to ensure all newly added and updated NERIS fields are correctly captured and formatted across report types, while maintaining legacy NFIRS behavior for previously authorized reports.
   

How it works:

1. The backend print logic has been updated to dynamically include any new NERIS fields introduced.
2. The system checks the report type and status:

• If the report was authorized under NFIRS, the print output will exclude any NERIS-specific data and mirror the legacy NFIRS format.
• If the report is under NERIS, all new fields will be printed and formatted according to updated specifications, ensuring complete data capture.

6. Pull Riding Position from Scheduling

1. Automatically populate riding positions from the Scheduling module when the "Tie Personnel from Scheduling into NFIRS" setting is enabled.
   

How it works:

1. Speak with your Client Success Manager to ensure that "Tie Personnel from Scheduling into NFIRS" is enabled, the system then pulls riding positions from the Scheduling shift board.
2. For each personnel assigned to a shift, their riding position will be automatically populated based on the Scheduling data.
   
1. Create riding positions within Fire Incident Setup > Response > Riding Positions
   
2. Once created within Scheduling > Setup > Edit / Create Assignment > assign positions
3. If the setting is not enabled, users must continue to manually assign riding positions as done previously.
4. The master list of riding positions is still maintained in the existing Fire Documentation configuration area.
   

1. Automatically transfer data from the nfirs_notification table to the incident_report table upon record creation, eliminating the need to manually trigger the sync.

---

Enhancements

1. This enhancement introduces targeted fixes to the incident report export functionality and the handling of casualty records, particularly focused on correct formatting, proper saving of custom field values, and file structuring for provincial validation.
   

1. When generating a report, casualty records are now automatically assigned a padded, three-digit identifier.
2. The custom field for “Number of persons who self-evacuated” is now stored and mapped correctly during report creation and export.
3. When exporting multiple reports in a batch, the system generates only two consolidated files based on the selected period and includes all authorized data entries.
4. Multiselect fields now export with clean formatting—ensuring compatibility with provincial data processing tools.
5. The firefighter casualty report template has been reviewed and adjusted to reflect the correct order of PPE fields based on the tested input sequence.

1. Enable the export of the “Action of Casualty” field as a single-value entry for Ontario OFM extracts.
   

1. When generating an OFM export for Ontario, the system now extracts the “Action of Casualty” field as a single-value string. If multiple selections exist in the system, only the first selected value will be exported. This ensures compatibility with OFM’s expected data format and prevents extraction failures.

1. Improved performance and scalability by restructuring how Incident Types are stored and referenced in NERIS.

1. The Incident Types, previously stored in a single array, are now separated into three dedicated fields for improved query performance and maintainability.
   
2. All modules that referenced the old structure—such as Fire Incident Setup, Fire Incident List, and the NERIS Form—have been updated accordingly.
   
3. Field providers were reviewed and adjusted to ensure workflows and custom fields continue working seamlessly with the new model.
   
4. This change prepares the system for future scalability and eliminates known performance risks.
   

1. Improved the import wizard by supporting additional date formats, enhancing validation messaging, and handling null values more gracefully.

1. When users upload a file through the import wizard:
1. The system now accepts both mm/dd/yyyy and m/d/yyyy formats for date fields.
2. If an incorrect format is used, error messages now clearly state the expected format (e.g., “Please provide a valid dispatch date. Format: mm/dd/yyyy”).
3. The wizard allows dispatch notified date to be empty or null, avoiding unnecessary import failures.
4. A cross-check is performed between the incident type selected in the UI and the actual incident type in the file to ensure consistency and accuracy.When users upload a file through the import wizard:
1. The system now accepts both mm/dd/yyyy and m/d/yyyy formats for date fields.
2. If an incorrect format is used, error messages now clearly state the expected format (e.g., “Please provide a valid dispatch date. Format: mm/dd/yyyy”).
3. The wizard allows dispatch notified date to be empty or null, avoiding unnecessary import failures.
4. A cross-check is performed between the incident type selected in the UI and the actual incident type in the file to ensure consistency and accuracy.