Please allow nativeNum FIT fields to override native fields in Garmin Connect

"So if you write Power data as a nativeNum from your field and I do as well, and Garmin also writes true native power, how would Garmin Connect disambiguate it? Maybe within the Garmin Connect system in general, or on an Activity basis, we could select which of the three (in this example) it should use as the "native" Power for calculation on calories, training load, etc?"

That's a great question, and I think the answer would be that Garmin will never fulfill this feature request, so it's a moot point.

Obviously the intent behind this feature request is that Connect would completely override true native fields (such as distance, power, etc) with the corresponding CIQ nativeNum fields.

Your question kind of suggests one of the reasons Garmin does not want to do this - what happens when apps write bad nativeNum data for power/distance/etc? Customers will probably point their fingers at Garmin.

I don't think it's a solution to allow customers to select the data source, as it's just more work for Garmin and more confusion for the end user.

Even strava doesn't allow you to select the power data source for running - if real native power is present, then it's always used, otherwise CIQ nativeNum power will be used if present. That's why if you want Stryd power to be used in Strava, you have to disable native running power. (Ofc it's no issue for the Stryd app, since Stryd will naturally ignore native Garmin power in favour of Stryd power.)

Good clarification. So if you write Power data as a nativeNum from your field and I do as well, and Garmin also writes true native power, how would Garmin Connect disambiguate it? Maybe within the Garmin Connect system in general, or on an Activity basis, we could select which of the three (in this example) it should use as the "native" Power for calculation on calories, training load, etc?

To be clear, this feature request is only asking Garmin to alow nativeNum fields written by CIQ apps to be treated just like native data in Connect (and to override any native data that's be written to the same FIT file).

It is *not* asking Garmin to make it so that when a CIQ uses the nativeNum option, it actually writes the data to the FIT file exactly like native data. The reason I didn't ask for that is because I am 100% sure Garmin would never do that.

Yeah, if CIQ data fields could actually write *literal native data* to the FIT file (and prevent the same native data from being written by the activity), that would accomplish things like Strava (and other 3rd party sites) automatically recognizing such data without any additional work on their part. But I don't think Garmin would ever implement that.

> They just want our money

Also, water is wet and the sky is blue

> Garmin favors and allows only THEIR app native fields it does not allow SwimSports to be published across to Strava o

The current behaviour described in this feature request doesn't prevent Strava from using nativeNum FIT fields.

As a matter of fact, Strava will accept power as a CIQ nativeNum FIT field (e.g. when Stryd Zones writes it), as long as actual native power hasn't also been written. (Native power always takes precedence over CIQ nativeNum power).

If Strava doesn't accept distance (for example) as a nativeNum field for swimming activities, then you will have to take that up with Strava. If the data is there, it's Strava's choice to accept it or not.

Even if Garmin fulfilled this feature request, it would not mean that Strava (or any other 3rd party site) would automatically start using nativeNum fields in favour of actual native fields. That would be additional work on their end. Nothing in the current behaviour prevents them from doing so, and nothing in this feature request would help to do so.

Agree! please.