Welcome to the ConnectWise Control Feature Request Portal

If you do not have an account, click "Sign in/ Sign up" to get started.


Tips

  • Search for an existing improvement or feature request before adding your own. This helps us prevent duplicate entries and track all suggestions.
  • If you find a matching request, give it a thumbs up and throw in a comment.
  • If you can't find a request for an item you need, create your own request. Provide as many details as you can, especially regarding possible use cases.

Rules

  • No spam, advertising, or self-promotion.
  • No offensive posts, links, or images.
  • Only one request per post.
  • Administrators have the ability to moderate the forums, including editing, deleting, and moving posts. Posts may be deleted for any reason, with or without notification.

Thank you for sharing your thoughts with us!

Recently updated feedback 1,548

+18
Considering for Future Release

Add Support for TLS 1.3 in Mono for Linux Self-Hosted Systems

J Copeland 2 years ago updated by Centicon 11 hours ago 21

Please add proper support for TLS 1.3 in Mono so that Chrome/Firefox users don't have to disable TLS 1.3 to make ScreenConnect work.

Related KB: https://docs.connectwise.com/ConnectWise_Control_Documentation/Technical_support_bulletins/Can_no_longer_load_Control_website_after_updating_Chrome

Answer

The community has had success with a workaround for this issue. This may work for your situation. https://tylermade.net/2017/05/04/easy-ssl-for-screenconnect-with-nginx-reverse-proxy/

 

+31
Considering for Future Release

Whitelist custom extensions in 6.5+

shawnkhall 2 years ago updated 1 day ago 10

Background: Control 6.5 imposes a signature validation scheme to ensure the integrity of the Connect install (per this post). This is a net good for most of the community base. For the rest of us it's more trouble than it's worth.


Request: We need the ability to either whitelist custom extensions from validation or disable the signature validation scheme entirely.


Reasoning: I've developed quite a few extensions in an on-premise Control installation to automate significant portions of my business. I'm not willing to share some of this code since it exposes the inner workings of my business, sometimes usernames and passwords, trigger URLs, and plenty of other information that would be useless for the rest of the world, but could increase the risk of my own business data should it be shared with a third party -- even ConnectWise. Microsoft, Google and Adobe have each been hacked in the past, so it's safe to assume that anything I share with CW will eventually be exposed as well.


The hosted developer instance option requires me to share business logic and requires significant rewrites to the code for each of my extensions to be able to prevent business information exposure. Furthermore, as far as I can tell, some of the functionality can not be rewritten in a way that prevents this exposure.


I've submitted an extension to CW in the past and it took weeks to have it approved. It took weeks to be approved for a developer instance. I can only imagine initial approval of each of my extensions to be able to use them in my own on-premise install will take weeks as well, and even minor updates to my extension (such as cosmetic changes or field formatting) will likely take weeks to be approved as well. 


On-premise users require the ability to continue to use and develop our extensions without exposure to ConnectWise. Please enable us to whitelist our custom extensions within the web.config so we can maintain the integrity of our own installations and source code.

+1
Pending Review

Enter a red arrow pointer onto connect wise session

bill 1 day ago 0

Hello, I've been using Connect Wise for over a year now and work with many individuals and businesses.  A convenient requested feature is listed in the header of this notice.  I'm wondering when this would be available for IT's to utilize and how we could enable this feature.  The sooner the better!  To just use the drawing tool is rather cumbersome and ineffective.

Thank you,

Bill Marks

Computer Training & Support Services, Inc.

847-736-2326

email:  bill@ctandss.com

+113
Under Review

Be able to apply app.config settings per session group

Steven 4 years ago updated by Erik van Putten 1 day ago 35

Be able to apply App.Config files or settings based on the Session Group(s) a computer is in.

CW#7546987

+17
Considering for Future Release

Some app.config settings on a per user basis

David Norelid 3 years ago updated by Brandon Wilcox 2 days ago 13

I'd like to see more settings available on a per-user rather than per-endpoint basis. One example:


I use SC to do remote support for my clients. I'm almost always connecting in when they're there, so I never want to blank the monitor. I've provided access to SC for a client who wanted access to their own PC, so i created a user, customproperty with their name to give them access to their PC only, all that jazz. They can log in and use SC to connect to their PC and only their PC. They want the ability to blank on connect by default because they'll only be connecting to their PC when they're out of the office, so they don't want anyone snooping around and looking at what they're doing remotely. However, this is the same SC install on their PC that I connect in to when I support them while they're in the office, so I don't want it to blank. Setting the app.config on their computer would make it so that no matter who connected, they'd get blanked, which isn't ideal. If the preferences were attached to the user, then they'd get the blanking default they wanted, no matter the computer they connect from or into, and I'd get my non-blanking that I want.

0
Pending Review

Manage Credential, separate permissions per features

framirez 2 days ago 0

Can you separate the permissions in "manage credentials"?

I mean, we want some users to be able to "Prompt for Storage" but we want other users to be able to "Send to Screen"

+6
Considering for Future Release

Add ability to config client-side proxy during installer build

anonymous 4 years ago updated by OTA 2 days ago 9

Partner wants to "bake in" proxy settings instead of using the tray icon on the client.

0
Under Review

Force 2FA everytime option

Intraworks 3 days ago updated by Caitlin Barnes (Product Manager) 2 days ago 1

Haven't seen this yet, but with so much MSP hacking... we'd appreciate the option to force 2FA every time (not just a new browser)    Its only a matter of time before a tech gets compromised.

Option to select Force 2FA Always either by tech or everyone is just fine.

+19
Pending Review

Allow remote printing, that once turned on manually, stays on after disconnects, until disabled manually

david 9 months ago updated by Andy Boyet Borja 3 days ago 6

I have clients that use the remote printing feature of ScreenConnect daily, but after updating to v19.0, remote printing now needs to be toggled manually each time the host connects. I would like it if once remote printing is enabled then it stays active even after the host disconnects, unless disabled manually.

+9
Started

SAML logout

Joe K 2 years ago updated by Noah Jarvis 3 days ago 14

Now that SAML is supported in 6.5 we need a way to log out from the IdP when we log out of ScreenConnect.  Please add support for the Single Logout URL or a custom Logout URL when using a SAML provider for authentication.  


Right now if I log out from ScreenConnect I stay logged into my IdP and I can get back into ScreenConnect without entering my credentials again.