Welcome to the ConnectWise Control Feature Request Portal
If you do not have an account, click "Sign in/ Sign up" to get started.
- 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.
- 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!
As an MSP who uses this product for multiple clients, we were concerned to realize that our clients setup with users to work remotely also have the ability to backstage into their machine. Now usually this is not an issue as they do not notice and mess with that setting, but we noticed a user recently who figured it out and although nothing was done inside of the session, is highly alarming to us that the only option currently is to either allow it for all users globally or turning on consent (which seems to be quite buggy) for all users which we also do not want as we use backstage as techs often and already have a gazillion MFA measures such as logging into ScreenConnect accounts. Is this something ConnectWise is already working on? It seems like quite the security risk with how it is setup now.
Now that Windows 10S is out and Applications are locked to the Microsoft Store - we need to still ScreenConnect to our clients using Windows 10S but cannot install the client. Can the client be added to the Microsoft Store?
When a new support session is initiated the customer gets a generic message to locate the download client file in the browser window. Many customers requiring ad-hoc support are not computer experts, so finding the download is often an issue for them. Edge has two locations depending on version, Chrome and Firefox have different locations yet the message tot eh customer is always the same.
Modification of the process is request to correctly identify the browser and version to correctly identify the location and method required to access the downloaded client file.
Current behaviour: When running tools from the shared mailbox it creates a folder in the user's documents. This cannot be changed at present.
Suggestion: Add the ability to change the default storage location. We would like to move this folder to the Root of C: so if another user signs in and requires an application that is installed per profile we won't have duplicate installers across different user folders.
Currently between the 3 CW apps (Manage, Control, Automate) I believe only CW Manage does this properly across the board. And by properly I mean it uses the native browser when doing SSO. Automate is the worst as both on mobile and on PC it wants to login using its own proprietary browser which means we have to leave it vulnerable because we cant implement simple logic based rules requiring a machine to be verified by us (Azure joined/registered). Control works on PC because its primarily accessed via browser but on mobile its similar to Automate where it uses the old method of "webview" I believe its called so it cant verify its coming from a compliant device. An update like this would probably do more for securing things than any of the recent hardening guidelines that were sent out
Windows 10 now allows the use of "PINS" instead of Passwords. Which is entirely a pain but it is what it is. ScreenConnect (Control) will let you store a password but not a PIN. How can we have "unattended" access if we can't store the PIN. I realize that a simple workaround is to add a user with a password but you would think that we could get better.
I would request EITHER a way to setup the PIN in the credentials OR a way to easily add a "username/password" for screenconnect. I know I can go into the users and groups and add it but that presents other issues.
I’m testing v21.5 at the moment and I’m overjoyed that login attempts are being logged now.
I see that this has involved the introduction of four “security event” types:
However, when I download my audit log using the ‘Download Audit Log as CSV’ extension, these event types aren’t included.
I’d like to be able to export login attempts in CSV form, so I really hope that this extension and the two report-generating extensions (‘Report Generator’ and ‘Report Manager’) will be updated in time for and in advance of the stable release of v21.5, rather than after.
Currently if a guest wants to remove a host from a session, they will right click the tray icon and end the session.
When a host joins a access session, there is no way of kicking them besides just stopping the services or uninstalling the agent. Feature request is for the ability to kick a host from a session without removing the agent.
Hello, I am currently using GoToAssist and Teamviewer for two different purposes and am considering ScreenConnect as a potential replacement. However, I know that Teamviewer will be supporting iOS screensharing but I do not know that Screenconnect will. If there are no plans to enable this feature in Screenconnect, then this will be a deal breaker for me.
Please add iOS screen sharing with unattended support. I am specifically looking at signing up with your Remote Access packages.
Customer support service by UserEcho