Topic
This article explains why travelers may appear as affected or receive location-based and travel alerts when they are not physically in the alert location at that moment, and how organizations can interpret these alerts in Everbridge 360™ Travel Protector and related Critical Event Management workflows.
Description
Location-based and travel alerts rely on snapshots of traveler data, event timing, and configured filters. As a result, a person can sometimes appear as affected or receive an alert even when not physically in the alert location at that moment. The sections below describe the main reasons this can happen.
Alerts based on event reporting time versus event start time
In earlier behavior, contacts and assets were correlated to a risk event using the event’s start date. If the event’s start date was earlier than a traveler’s departure, but the event itself was only reported later, the system could still associate those contacts and assets from that earlier start date. In practice, this meant contacts might receive notifications after leaving the affected area.
The correlation logic has been updated so that matching is now based on the risk event’s reporting time (when the event is reported to the system) instead of the event start date. With this change, only contacts and assets associated after the event is reported are correlated and can receive that alert. This fix has been deployed to production.
Alerts using a snapshot of travel and contact data
Travel alerts use the travel and contact data snapshot that existed at the moment the alert was generated. If a contact had an itinerary that placed them in the alert area at that time, they are included in the alert recipient list and traveler counts, even if that itinerary is later deleted or changed.
Because the alert’s traveler counts reflect the state when the alert ran, a deleted or modified itinerary can still cause a contact to appear as affected in the alert history, even though the itinerary no longer appears when the traveler link is opened afterward.
Expected and upcoming travel in proximity alerts
Visual Command Center (VCC) proximity alerts within a Critical Event Management workflow can be configured to notify based on expected or upcoming travel, not only current presence. If a contact has a travel plan indicating they will be inside the alert radius (for example, arriving the next day), that contact appears in the proximity alert as an expected traveler.
To prevent upcoming travelers from appearing as affected, organizations can open the alert’s filters and deselect the option that includes travel or upcoming-travel contacts. With that option disabled, results are limited to contacts whose travel plans indicate they are currently in the location at the time of the alert.
Stale last known location data (resolved issue)
In some cases, a location-based alert could previously target people for a city they were no longer near because the notification selection logic used stale last known location entries. For example, an outdated last known location such as a previous stay in Philadelphia might cause a contact to be selected for a Philadelphia alert, even after leaving.
This behavior was due to a known product bug and has been addressed with a released fix. If similar behavior is observed, it should be checked against the current product version to confirm whether the fix has been applied in the relevant environment.