nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

New Track ID Requirement for Real-Time Analytic Tools Supporting Dynamic Geofencing and Joins

Jeff_G

The February 2026 ArcGIS Velocity update introduces changes to real-time analytics that improve overall stability and performance. These improvements include a new requirement for certain real-time workflows that use dynamic geofencing and dynamic joins.

What’s changing?

Real-time analytics configured with a feed connected to the join port of the following tools must now include a Track ID field:

Join Features
Detect Incidents
Filter by Geometry
Calculate Distance

Who is affected?

If you have a real-time analytic that uses a feed connected to the join port of any of the tools listed, and that feed does not include a Track ID field, action is required.

What You Need to Do Before the Update

To avoid interruption, review and update affected real-time analytics before the update to ensure all feeds connected to a join port include a Track ID field. See the How to Update Affected Real-Time Analytics section below for step-by-step options.

What Happens After the Update?

Analytics that are updated ahead of time will continue to run normally after the release. However, any real-time analytic that still uses a feed connected to a join port without a Track ID will be stopped and not executable. When this occurs:

The analytic will remain in a Stopped or Not yet run state
A validation error will be displayed indicating that the Track ID field is not defined
The analytic cannot be started again until the validation error is resolved

How to Update Affected Real-Time Analytics

Option 1: Configure a Track ID on the Feed

Update the join feed so it includes a Track ID field. Learn more about Track IDs in Velocity feeds.

Option 2: Use the Map Fields Tool

Connect the join feed to the Map Fields tool and assign the TRACK_ID tag to an existing field or to a newly created field. Learn more about the Map Fields tool.

Note: For either option, the Track ID field should be a unique identifier. If the Track ID field contains null values, the performance of the real-time analytic may degrade over time.

What Is Not Affected?

If your real-time analytic does not meet the criteria specified above it will remain unaffected, including ones that have:

Join feeds that already have a Track ID configured
Static sources

All other Velocity items such as feeds and big data analytics are also unaffected.

Find more posts tagged with

Comments

Jeff_G

@rflorence The Track IDs can be different for the target and join feeds. Your target feed can use Vehicle ID and the join feed can use Group ID. The outgoing schema for the tool should still use the Vehicle ID field as Track ID for the data going downstream.

rflorence

Yes @Jeff_G , I am ok with Group ID and assign it as a Track ID for the incoming feed, but just don't want to use it , as my Vehicle ID is the Track ID for the other input feed and I need that in my second downstream join which already contains Vehicle ID/Track ID on both input feeds. Hope this makes sense!

Jeff_G

@rflorenceThe Track ID was always a requirement for feeds connected to the target port of the tool. This update made it required for the Track ID to be defined on the join feed as well. The Track ID can be any field within the schema, and yes it's only a recommendation to use the primary key/unique identifier field.

For your use case, can the Group ID field work as the Track ID for that feed?

rflorence

@Jeff_G is the Track ID just required to be defined on the feed coming into the join, and it is only a recommendation to make that the primary key? We track by a Vehicle ID as the primary Track ID and join to a Vehicle Groups feed using another field called Group ID, as we have to persist the Vehicle ID all the way to the Hosted FL output. The Group feed does not contain Vehicle ID (many vehicles are in the same group - and the logic has worked fine). Thanks!

Jeff_G

@JeffSilberberg The Track ID requirement was introduced as part of broader work to improve the stability and performance of real-time analytics. For tools that support dynamic joins and dynamic geofencing, the join port maintains an in-memory set of features over time. Requiring a Track ID allows the analytic to consistently identify a unique feature and ensures that only the most recent observation for for a given Track ID is kept in memory. This is important for predictable behavior and for keeping analytics stable as they run over long periods of time.

Historically, this requirement was only enforced on feeds connected to the target port. We're enforcing it on feeds connected to the join port so that both sides of these workflows behave consistently.

In your scenario, using feeds instead of static sources makes sense, since the tables are updated periodically and those changes need to be reflected without restarting the analytic. Are existing records on the feature layer table getting updated? If so, I'd recommend using the same primary key that is being used to update those records as the Track ID.

If there is no obvious field to use, I recommend using the Map Fields or Calculate Fields tool to define your own Track ID. For example, the Watch Center solution uses Map Fields with an Arcade expression on a new field to generate a new unique identifier by concatonating two existing fields. This field is then tagged as the Track ID field.

JeffSilberberg

@Jeff_G

So we have any number of RTAs that this will impact. As we have static tables (Feature Layers) that only get updated maybe a dozen times per month with a minimum number of entries impacted, but the nature of the RTAs (7/24) that include dynamic geoFences and Incidents is such that they can not be restarted without losing critical data. Therefore, these tables are brought into the RTAs as Feeds since the person making the change has no real insight into what RTA might need to be restarted, has no authority to restart RTAs, and losing the states in the RTAs is not reasonable.

I do not see the advantage to a Track_id (Primary Key?) on these Tables, not even sure in some of them which column I might designate as a Track_id. Can you expand on the change, and if there is a better way to consume these tables into the RTAs?

Michael_Knapp

Perfect, thanks for clarifying @Jeff_G

Jeff_G

@Michael_Knapp Dynamic attribute-based joins are also affected too. If your join feed does not have a Track ID specified, then your real-time analytic will be affected.

Michael_Knapp

So, if there are feeds connected to a "Join_Features" tool, but are not involved in dynamic geofencing, does that mean this change will not impact the RTA?

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.