Troubleshooting Missing Last Known Location (LKL) Data in Visual Command Center (VCC)

2026-09-03 18:36:10 UTC

Problem

Administrators expect a contact's Last Known Location (LKL) to appear in Visual Command Center (VCC), but the LKL data is missing or appears incorrect. In some cases, LKL data is visible elsewhere in Everbridge Suite (for example, Universe or reports) yet does not display in VCC. This affects situational awareness, location-based alerting, and map visibility for contacts and assets.

Root Cause

Missing or incorrect LKL data in VCC can have several causes:

  • No LKL records exist upstream: The contact has no LKL entries in Everbridge Suite, so VCC has nothing to display.
  • Inactive LKL source: No recent geolocation data has been received from a supported source — mobile-app events (SOS, Safe Corridor, Check-In, Emergency Call, solicited messages, auto check-ins), dynamic-location CSV uploads, or access-control (C•CURE) badge data.
  • Contact or asset configuration: A missing or incorrect Location ID 1, or a missing asset associated with that location, prevents LKL from attaching to the correct location.
  • VCC filters: Timeframe filters in the Last Known Location panel, or map and console filters, hide valid LKL events.
  • Expired records: An expired LKL, or a CSV record whose expireDate is at or before the batch receipt time (often from non-UTC timestamps), is treated as expired and ignored.
  • Mobile device or app settings: Disabled GPS, missing app permissions, no recent Safety Connection activity, or poor reception produce null or incorrect coordinates (for example, 0.00000, 0.00000).
  • Access-control ingestion: A C•CURE dynamic-location source that is not configured, or readers that are not mapped, so badge events do not become LKL updates.
  • Display state: A stale browser or feed, or the wrong organization selected in the VCC Console, hides contacts and LKL data until corrected.
  • System-level data handling: Location services and permissions are correct, but the system records null or zero coordinates across multiple events, which indicates a deeper data-handling issue for support and engineering.

When configuration and filters are all correct but LKL still does not display in VCC while it exists in Everbridge Suite, detailed reproduction steps and diagnostics (including an HTTP Archive (HAR) file and timestamps) are needed so support can investigate how VCC handles and displays location data.

Solution

Use the following steps to diagnose and resolve missing LKL data in VCC.

1. Confirm Where Location Data Should Appear

First, confirm which Everbridge features the organization has enabled and where LKL should be visible:

  • Universe (Everbridge Suite): The Universe Map tab shows contacts by Last Known Location and Expected Location, and displays check-ins and static (geocoded) locations. Click a contact symbol to view details.
  • Visual Command Center (VCC): Panels display Last Known Locations and Expected Locations for a selected contact, each with a timeframe filter, and support geofencing (Watch Zones) and asset feeds for location-based alerting.
  • Assets feed requirement: VCC displays assets and contacts on the map only when the Assets feed is enabled.
  • Organizations without VCC: Some organizations do not have VCC enabled. In those cases, Universe is the primary map-based view for check-ins and static locations.

2. Verify That LKL Records Exist in Everbridge Suite

VCC can display only LKL data that already exists in Everbridge Suite.

  1. Determine whether the contact has any LKL records in Everbridge Suite (for example, through Universe or reporting).
  2. If the contact has no LKL entries there, VCC-specific troubleshooting cannot resolve the issue until upstream LKL data is generated.

2.1. Confirm the LKL Source

Confirm the system is receiving geolocation data from a supported source:

  • Mobile-app events: SOS, Safe Corridor, Check-In, Emergency Call, solicited messages, and auto check-ins.
  • Dynamic locations uploaded via CSV using Upload Dynamic Locations.
  • Access-control badge data ingested from C•CURE 9000.

If the contact has not recently sent location data from the mobile app, no dynamic-location CSV has been uploaded, and no access-control events have been ingested, there may be no LKL records to display.

3. Validate Contact Profile, Location ID 1, and Asset Configuration

Confirm the contact and asset configuration so LKL can attach to the correct location:

  • In the contact profile, confirm the Location ID 1 field is populated.
  • Under Contacts and Assets, confirm the referenced location exists and that the asset associated with Location ID 1 is present. If the asset is missing, add it.

A contact must have at least one location recorded in their contact data to be included in location-based alert areas. A contact with no location in their profile may not be visible in VCC and is not included when an alert targets a geographic area, so that contact does not receive the mobile-app notification. Add the appropriate location to the contact's record, then confirm visibility in VCC.

4. Check VCC Timeline, Map Filters, and Organization

  • Timeline panel: The Last Known Location panel has a timeframe filter. If the range is too narrow or excludes the contact's location events, no LKL entries appear. Widen or reset the timeline to include the relevant period.
  • Map and console filters: Map and console filters can hide contacts and assets. Review these filters and clear or correct them so contacts with valid locations display.
  • Organization selection: Confirm the correct organization is selected in the VCC Console. Contacts in a different organization do not appear.

After adjusting the filters, re-check whether the contact's LKL events appear. If a contact's LKL has expired, the dynamic location data is no longer available and does not display when filtering by Last Known in VCC; a fresh LKL update is required in that case.

5. Confirm Location Data Is Being Sent to the System

If LKL records appear incorrect or do not update, confirm the source is providing usable data.

5.1. Mobile App Geolocation Breadcrumbs

Last Known Location updates when the system receives geolocation data from the mobile app. When coordinates look wrong (for example, 0.00000, 0.00000) or do not update, check that:

  • Device-level location services (GPS) are enabled.
  • The Everbridge mobile app has permission to access device location, with foreground or background access as required.
  • The user recently triggered a Safety Connection feature (SOS, Check-In, Safe Corridor, or Emergency Call), which reports location to the system.
  • Local GPS reception is adequate (for example, not inside a building or an area with poor signal).

If location services and permissions are correct but the system records null or zero coordinates across multiple events, the behavior indicates a systematic data-handling issue that requires deeper technical investigation.

5.2. Dynamic Locations Uploaded via CSV

For contacts whose LKL comes from dynamic-location CSV uploads, confirm the data is valid and not expired:

  • Inspect the arriveDate and expireDate fields for affected records. Both are treated as UTC, and expireDate must be later than the batch receive time and in the future at upload.
  • Compare each record's expireDate to the server-side batch receipt time. If expireDate is at or before the batch receipt time, the record is treated as expired and ignored, even when the file loads without syntax errors.
  • Confirm timezone handling in the system that generates the file. The service expects UTC; convert local timestamps to UTC before upload.
  • Confirm identifier mapping: Location ID must match the system's building or asset ID, and the contact's external ID must be correct, so valid records can attach to contacts.

If timestamps or identifiers are incorrect, regenerate the LKL records with correct UTC expireDate values and mappings, then re-upload. After valid, non-expired data is uploaded with correct IDs, dynamic-location badges appear on contact records and in VCC.

5.3. Access-Control (C•CURE) Badge Data

For contacts whose LKL comes from C•CURE 9000 badge events, confirm the integration is configured and mapped:

  • Confirm a dynamic-location source exists for the organization. A missing source produces a DYN_LOC_SOURCE_NOT_EXIST error; add a location source named "CCure9000" under Settings > Organization > Contacts/Assets > Location Services.
  • Confirm every reader is mapped to an Everbridge location. Unmapped readers produce a DYN_LOC_INCOMPLETE_LOCATION_INFO error; map each reader under Settings > Everbridge Open > Settings > Reader/Location Mapping (or in the iPaaS integration).
  • Confirm the incoming feed includes a reader identifier for the contact's events, and that the dynamic-location files were ingested at the expected times. A gap in ingestion causes contacts to show the older location until files resume.

6. Perform Basic Map, Feed, and Browser Refresh Steps

  • Although the VCC map updates dynamically, manually refresh the feed or reload the browser page when data is expected but not visible.
  • For similar reports of contacts not appearing on the Universe or VCC map, a browser refresh while signed in has restored the contacts display.

If contacts or LKL data still do not appear after a refresh, continue to data collection.

7. Reproduce the Issue and Capture Evidence for Support

When LKL data exists in Everbridge Suite but does not appear in VCC despite correct configuration and filters, gather detailed diagnostics for support and engineering.

7.1. Reproduce the Missing LKL Behavior

  • Select the affected contact in VCC and confirm the Assets feed and the relevant panels (Last Known Locations, Expected Locations) are visible.
  • Set the timeline and map filters so the expected timeframe and location type (Last Known Location) should be visible.
  • Confirm the contact's LKL records are present in Everbridge Suite at specific timestamps.
  • Note the exact time (including timezone) when the LKL should appear in VCC but does not.

7.2. Capture a HAR File and Supporting Details

  • Generate an HTTP Archive (HAR) file from the browser while reproducing the failing request where the Last Known Location does not load.
  • Capture screenshots that show the exact map and filter settings, including which location types are selected.
  • Document the contact name(s) and External ID(s), and any visible timestamps such as arrival date/time or last updated.
  • Indicate whether the contact's LKL shows as expired in any upstream view.
  • If possible, include an alternate contact currently exhibiting the same problem so engineers can reproduce it with multiple examples.
  • Record the precise timestamps when the LKL exists in Everbridge Suite but fails to display in VCC.

Include the HAR file, screenshots, contact identifiers, and exact timestamps when opening the support or escalation request. This package enables targeted investigation of location-data handling and VCC display logic.

Workaround

If the underlying cause cannot be corrected immediately (for example, a deeper system-level issue), the following provide interim visibility while support and engineering investigate:

  • Use Universe and other upstream Everbridge Suite views to confirm LKL records exist and to monitor contact locations, since Universe may display the data when VCC does not.
  • After confirming device location services and app permissions, ask affected users to perform a fresh mobile-app check-in or Safety Connection action to generate a new LKL update.
  • If LKL comes from CSV, regenerate and re-upload corrected files (with UTC timestamps and correct identifier mappings) so new, valid records appear.
Was this article helpful?
0 out of 0 found this helpful