This should be obvious. In Control triggers, there should be a simple checkbox for each trigger to enable / disable the trigger. Yes, I know we can add a AND 0 or something to that effect but it would be nicer to simply turn off a trigger without deleting it.

I would like a way to assign a code to each technician so that when they create a new session, their assigned number is the session number. But if the user has not been assigned a code, it defaults to the normal random 4 digit session code.

Example:
User       Session Code Assignment
Daniel     0
Jim         1
Alex

When Daniel clicks "Create +" the session is made with a session code of 0
When Alex clicks "Create +" the session is made with a system generated session code

Currently when I connect to a guests machine and start a chat with them, it only displays "Guest" as their name.  I would like the currently signed in account on the machine to be the username that displays in the chat logs.  We have devices used by many different users.  So when looking back through conversation logs it is hard to identify which person the conversation was taking place with.

When you connect to a server the screen resolution can be quite small and there is no way to change the default window size, having the ability to change or set a default connection resolution size or control it in the session would be very helpful, it is very frustrating when you are viewing a sever at 800x600 when you have 1920 x 1080 monitor.

Older graphics cards restrict screen resolution. This is not a problem with the Microsoft Terminal Services client which uses a virtual driver and can display much higher resolutions.

The addition of Duo push 2FA is great but a bit puzzling. Why only support push when Duo supports so many authentication options and they make it easy to implement them all.

• Some people don't have a smartphone where they can install the Duo app so push won't work for them but they can still receive a text message of phone call just fine. Duo supports both of these options for 2FA but Screenconnect's Control's integration was is implemented in a way that does not allow them.
• Some people might have multiple devices with the Duo app installed and need to choose which one they want the push sent to. Duo allows users to choose which one they want to receive a push from, or which one they want to receive a text or call on. Again Control's integration does not allow this.
• Ever forgotten your mobile phone at home? I have and that's why I've configured my Duo account with a hardware token too. Unfortunately Control's integration does not support this Duo 2FA method either.
• Perhaps you are prone to forgetting your mobile device but don't want to have a hardware token. In this case Duo can be configured with bypass code (basically a OTP that you know beforehand). Well, you know the story.

I'd really like to see Control support the all the Duo authentication methods and for the looks of their documentation this should be relatively easy.

As an added bonus this also provides a natural way to handle the 2FA logon rather then show the user a prompt for a code that they can't type (what your Duo 2FA currently does).

Currently when we run a tool on 100+ systems the toolbox does not load on a new connection until the process has completed.This can take several minutes until the toolbox is available on a device. This can cause delays with support.

make the commands tab a full-interactive PowerShell

would like to send multi-line commands

While viewing the timeline from the web interface, each event has a corresponding date & time shown to the left.

I have devices with events as far back as 1-2 years ago, but the displayed date only provides the month and day.

Please add the year to the Timeline's event dates.  

**Requiring us to hover over the date string to display the full date, (including the year), would also work.

-- Forum thread about same topic with response from Scott:  https://controlforum.connectwise.com/yaf_postsm40018_Web-Interface--Timeline--How-to-show--Year--in-displayed-dates.aspx#post40018