Product Ideas Portal

Got an idea for a new feature? Maybe a tweak to make something work even better? Wish there was an integration with another product to make you even more productive? You've come to the right place.

The Product Ideas Portal lets you submit whatever product feedback you have, good, bad, ugly, and anywhere between.

Want to stay anonymous? Don't worry, no email address or name fields are shared on the public portal. You can create an account which lets you vote on other people's ideas and receive updates when your idea's status changes.

To learn more about how an idea becomes a feature, check out this infographic.


23 Vote

Backwards Compatibility Jump Client and Rep Console

Previous versions (at least 1 back) should be compatible with any appliance upgrade. When self-update works then the current model doesn't present any issue, but new installs or reimaged computers in our environment require a new install of the client or rep console and the previously deployed installer won't work after the appliance upgrade. I can't generate a jump client installer until after the appliance upgrade which leaves a small window where a new install hasn't been deployed and the old will no longer work. Previously deployed installer should still install an outdated version, check in with the appliance and then self-update.

  • Guest
  • Nov 27 2018
  • Under evaluation
  • Attach files
  • Guest commented
    5 Apr, 2019 02:35pm

    Installed Jump Clients receive a token from the appliance, which allows them to still communicate and self update after an appliance update. Why can't the same token concept be baked into a Jump Client installer (.MSI or .EXE) when initially created? That would solve the issue and save everyone a lot of time from having to remake images and rebuild packages simply to accommodate a new Jump Client installer every single time the appliance runs an update.