Garmin - change in sync behaviour?

Komoot, Strava and PlotARoute offer features to sync routes from their platforms to GArmin.

In the past, it seemed to be (and this seems confirmed as both Komoot and PAR mention this in their own support articles) that setting up routes for sync (for example, starring them in PAR) would mark them for syncing to GC and then the user can manually send them onto a device

So for example PAR say that "Once a route has been transferred to Garmin Connect you can sync it with your Garmin devices, following the instructions on Garmin Connect. If your device supports bluetooth, you can sync it using the Garmin Connect mobile app, otherwise you'll need to download the Garmin Express transfer software, which will transfer the route from your computer."

This behaviour has seemingly changed that any such a route now AUTO syncs to your device as well. This behaviour may be problematic for people with multiple devices.

Can anyone else confirm (with Strava, PAR or Komoot accounts) this behaviour? And if so, Garmin, can this be please looked at?

(Forwarded to Garmin support as well

  • That's weird as the PAR and Komoot documentation mention it has to be pushed from GC, and I could have sworn it never did in the beginning - but yeah, it's not right.

  • That is correct. Once it went to the Edge unit it will stay there until you delete it. Then to have it back you need to think about unstaring it and starring it again for it to transfer again.  on top of that this is not a true sync since if you modify the route it won't get updated (was not, didn't test that for a while). Poor design.

  • The updating at least does seem to work these days, even though I don't 100% trust it!

    With a route already sync'd from say komoot -> GC -> device, edit the route within komoot and it updates the copy within GC and then the device on next device sync. Most of the time.

    That said, if I know a route has been modified, I still always 1) manually delete it from my device, 2) double-check a key detail in GC to make sure it matches the updated route within komoot (eg. the distance usually, or I stick a v2 on the route name), then manually "Send to device" within GC. Belt and braces!

    Interestingly, if you use the komoot on-device app, it appends the course name with a random number.. presumably to aid it keep track of it and updates etc.

  • Poor design

    Definitely feels more like a hack/bodge vs. long-term solution, you'd think Garmin would want to work with these providers to offer an API to allow a more integrated approach - win/win/win for Garmin (£$) / 3-parties (£$) / consumers (ease of use).

    Though, getting back on topic, a seemingly simple 'fix' would be to just stop pushing everything from 3rd party platforms out to devices.. currently the sync between 3rd party and GC platform works reasonably well (albeit one-way only, can't delete from 3rd party side), then leave it for the user to push the routes they require to the device(s) they require. Less clutter = more manageable to clean up manually (ie. I'd only push a handful of routes to each of my devices a week at most, which I'd then mostly delete afterwards / weekly, all safe in the knowledge they are all available within GC if I wanted to push them out again, plus I can edit the master on the 3rd party site as and when knowing the updates will be again sync'd to the GC courses repository, ready to be pushed to my device). All with the tools already available today (GC mobile app, GC website). Simples.

  • Much as I have had excellent support from Garmin in the past, sometimes it’s just… missing the point

    reply to my follow up

    Due to the nature of internet forums, people will express their personal views which they are entitled to do and we have no control over this. Our preference would be for them to contact us first so that we can offer support.
    You will likely therefore, find other users that have experienced similar issues to yourself, and the same can be found for any electrical device and potential issue, but these do only make up a very small minority of users, and very few of these turn out to be genuine faults. As such, whilst regrettably faults can occur, as they can on any electrical device, there are no known faults with these, which can cause this.”

  • A massive bugbear of mine, should read:

    "Due to the nature of many customer support representatives, who often have no understanding of the products they support, nor do they take the time to attempt to understand feedback/queries received from customers, sometimes not even reading them in full, customers will instead take to internet forums to engage in more productive conversation and peer support."

    I've lost count of the amount of times I've attempted to report a generic software platform bug, only to be first grilled on details like device serial number, model, colour etc despite my protests of "you're missing the point, it's got nothing to do with my device..".

    Occasionally you get to speak to someone who either a) understands the products/technologies or b) at least is openminded enough to entertain the idea you might know what you are talking about and look to work with you and pass the information to the right department - a breath of fresh air, though, sadly, rare.

  • I replied….

    Um you’ve missed the point.

    There is a difference in behaviour between syncing courses created with GC and third parties.

    1) courses created via GC are not automatically synced to the device. They require the user to perform another step, that is to select a course and send it to the device.

    2) courses created via a third party and synced via a api call automatically sync to GC as desired, but then automatically sync onwards to the device. If a user has multiple courses in a third party, or multiple devices, this step may lead to multiples being synced undesirably and leads to a loss of control of the syncing.

    I mention the forums as other users have tested and confirmed this behaviour, that third party course syncing bypasses a step to push the course onto the device with out user confirmation.

    That’s the behaviour we think should be changed, it’s not an electrical fault, it’s seemingly a design choice for third party api course syncing

  • Their reply

    I am sorry you are unhappy with this, this is how Garmin connect is designed.

    We cannot guarantee that what you have suggested will be implemented, however we do appreciate you passing along your opinions. Please share your ideas with us at the following page on our website: www8.garmin.com/contactUs/ideas/

    If there is anything else I can help you with then please let me know. Alternatively you can search for a solution here: support.garmin.com/en-GB/
    Kind regards,

  • The more I think about this, the more I see it as a bug - plain and simple - and the more it annoys me!

    A design decision has been made whether or not newly created courses should be automatically pushed, or not, to all linked Garmin devices. Clearly this design decision was NOT to do this, not only because frankly this is the only logical decision, but further demonstrated by the numerous places you have option to "Send to device" (web site, GC app and so on). Exactly the same model is followed for other components, for example PacePro strategies.

    How the course arrives on GC - either created by the user or sync'd across from a linked 3rd party site - makes no difference to this design decision.

    I can see what's happened here: one product manager, while evaluating the courses feature within Garmin Connect, made the sensible decision NOT to have new courses push to all connected devices by default. Clearly the right decision, as testing would have shown how very quickly this would otherwise become unmanageable (puts pressure on local on-device course management, which doesn't have the best interface, storage space, confusion for users, not to mention a exponential hassle for users with multiple devices). Then another product manager has come along and overseen the implementation of the 3rd party courses sync, and decided it would be better to "save an additional step" by insisting these 3rd party originating courses are automatically push out to devices. But without talking to the first product manager who would've had more knowledge on this and fully understood the pit falls.

    = poor that it has happened this way, very poor that when users have pointed this out it isn't being further looked into.

  • Agreed. GC should be the parking bay that courses go into, whether designed there, imported or synced from elsewhere. Then the user can decide which courses go where