Problem

In some organizations, badge or access control data is used to populate contacts’ Last Known Location (LKL) in Everbridge Suite through dynamic location uploads. Administrators may observe that badge-in activity does not appear as a Dynamic LKL on contact records, even when CCURE or other access control system files appear to upload successfully. In other cases, dynamic uploads show errors indicating that specific locations are not recognized by the platform.

Root Cause

Several platform behaviors can prevent badge-derived data from updating a contact’s LKL, even when files are delivered on schedule:

• Dynamic CCURE files are the LKL data source: In these configurations, CCURE dynamic location files are the source used to update contacts’ LKLs. The files are received on a regular schedule, and when dynamic location data is present it results in a Dynamic LKL being associated with the contact record. If a contact record has no Dynamic LKL, their badge-in location will not be reflected in the contact data until such dynamic location data is assigned.

• LKLs are time-sensitive and can expire: LKLs are time-sensitive location tracking features that typically have a validity period. For badge integrations, locations are recorded when a contact badges in, and these locations are usually set to expire after a specified time period. The Last Known Location feature tracks contact locations based on badge-in data, with a default expiration time of 8 hours. LKLs have a start time (Arrival) and an end time (Expiration) based on when an employee badges in and out of a location. If an LKL is expired when uploaded, it is ignored, and the existing LKL of the same source is deleted. LKLs are designed to track an employee's most recent location, with a typical expiration period of 24 hours.

• arriveDate and expireDate are interpreted as UTC: The platform treats both arriveDate and expireDate as UTC. If the source system generates timestamps in a different timezone or without converting to UTC, records may appear expired on receipt or show unexpected times. If an LKL’s timestamps make it expired at the time the platform receives the batch, the location will not be applied to contact records even if the file loads without errors.

• Location IDs must exist in the platform: Uploads can reference a locationId that does not exist in the system. In this case, the platform returns the error code DYN_LOC_LOCATIONID_NOT_EXIST, and those records are rejected. Rows with this error do not update LKLs.

• Missing CCURE connector configuration: If a CCURE connector is not configured for the organization, dynamic CCURE location data may not be processed as expected.

• Synchronization behavior: Although LKLs are updated from badge-in data, the system may experience synchronization delays, where the location timestamp might not immediately update in the contact's profile.

Solution

To ensure badge-based dynamic uploads correctly update Last Known Location in Everbridge Suite, administrators should validate configuration, data content, and timestamp handling using the following guidance.

1. Verify connector and dynamic upload configuration

• Verify whether a CCURE connector is configured for the organization. If no connector is present, dynamic CCURE location data may not be processed as expected.

• Confirm that CCURE dynamic location upload files are being received at the expected cadence and inspect for any gaps in the upload timeline.

2. Confirm that Dynamic LKL entries exist for contacts

• Review affected contacts’ records to see whether a Dynamic LKL entry exists and when it was assigned. If a contact record has no Dynamic LKL, their badge-in location will not be reflected in the contact data.

3. Validate that LKLs are not expired on arrival

• Confirm that the file successfully uploaded and appears as “loaded without error.”

• Verify that the contact external ID and the Location ID in the file match the expected contact and building asset identifiers in the platform.

• Check the arriveDate and expireDate values in the file and confirm they are valid relative to the upload time. If the expireDate is earlier than the batch arrival time (as interpreted by the system), the LKL entries will be treated as expired and will not sync to contacts or Visual Command Center (VCC).

• Because the platform treats both arriveDate and expireDate as UTC, ensure the timestamps in the upload are generated in UTC or converted to UTC before upload. If the source system generates timestamps in a different timezone or without converting to UTC, records may appear expired on receipt or show unexpected times.

4. Align badge-based LKL timing with business requirements

• Confirm that LKL validity periods match organizational expectations. For badge integrations, locations are recorded when a contact badges in, and these locations are usually set to expire after a specified time period. The Last Known Location feature has a default expiration time of 8 hours, and LKLs are designed to track an employee’s most recent location, with a typical expiration period of 24 hours.

• Ensure that expireDate values are set far enough into the future (in UTC) so that they are still valid when the platform receives the batch.

5. Resolve DYN_LOC_LOCATIONID_NOT_EXIST errors

• Understand that DYN_LOC_LOCATIONID_NOT_EXIST indicates the dynamic upload references a locationId that does not exist in the system, and those records are rejected.

• Verify that every locationId in the upload matches a valid location configured in the platform. If any locationId is incorrect or missing in the configuration, update the location data in the platform or adjust the file output to reference valid IDs.

• Recognize that rows with DYN_LOC_LOCATIONID_NOT_EXIST errors will not update LKLs, even if timestamps are otherwise correct.

6. Confirm ongoing file delivery and timing

• According to the provided information, CCURE dynamic location files can be received on a regular schedule (for example, hourly). Ensure that this cadence is maintained so that LKLs are updated in a timely manner and that new badge-ins are reflected before LKLs expire.

7. Additional considerations for synchronization

• Be aware that the system may experience synchronization delays in some cases. Even when badge data is processed and LKLs are valid, the location timestamp might not immediately update in the contact's profile.

For detailed guidance on formatting arrival date and time fields for dynamic location uploads, including required date and time formats and time zone designators, see the article EBS: Formatting the "Arrival Date and Time" for Dynamic Location Uploads in Everbridge Suite.

Workaround

If administrators cannot immediately modify the source system or integration logic to generate UTC-aligned timestamps or correct location IDs, the following approaches can help maintain usable LKL data until a full solution is implemented:

• Monitor dynamic upload results to identify and correct expired LKLs by adjusting expireDate values in future files so that they remain valid at upload time.

• Temporarily extend the validity period in the uploaded data (while still reflecting organizational policies) so that badge-derived LKLs remain active long enough for scheduled file deliveries.

• Manually validate and correct locationId mappings in the platform to eliminate DYN_LOC_LOCATIONID_NOT_EXIST errors, ensuring that future uploads referencing these IDs can successfully update LKLs.

These steps help keep Last Known Location data current and usable for notifications and situational awareness while longer-term integration changes are planned and implemented.