ScreenConnect Agent
ConnectWise ScreenConnect in Switchboard. Review AI skills, playbooks, access limits and setup requirements before connecting your MSP systems.
How the ConnectWise ScreenConnect integration works
ScreenConnect is how your techs reach client machines. Connect it and a session can read the whole remote-access picture: every unattended machine, every client folder, and the record of who connected where. Switchboard connects through an MSPStuff-hosted MCP server, so there's nothing to install and no API keys to hand your techs. Read-only today. No credential we issue carries a write scope. Any change the integration could make in ScreenConnect is held back — refused by our server before anything reaches ScreenConnect — until a person switches it on, and nothing is switched on today.
Hosted and external AI connections provide read-only access. Guidance, shared playbooks and automations we release for everyone are included with Dedicated. Bespoke automation builds are scoped separately. Any change a platform could make is held back — refused by our server before anything reaches the platform — until a person switches it on, and nothing is switched on today. Vendor consent does not switch any change on.
| Machine | Last seen |
|---|---|
| ACME-WS-04 | 9 days ago |
| HBR-LT-12 | 8 days ago |
| NTH-SRV-02 | 7 days ago |
Read-only today. No credential we issue carries a write scope. Any change the integration could make in ScreenConnect is held back — refused by our server before anything reaches ScreenConnect — until a person switches it on, and nothing is switched on today. The service account you create holds an administrator role on your own instance — ScreenConnect gates the access audit behind it — so what bounds a session is the scope we issue, not what that account could do.
What it can do
- Machines you can reachEvery machine set up for unattended access: which client it belongs to, what it runs, who was last signed in at it, when your instance last heard from it — and how to ask for one slice of that rather than all of it.4skills
- Inventory every machine set up for unattended access — client, operating system, agent version, signed-in user, idle time and last check-in.
- Open one machine's full record — its connection history, the events recorded against it, and the notes technicians left behind.
- Ask for just the machines that match a condition — still on an old Windows build, behind on agent version, quiet for months — instead of pulling the whole fleet and sifting it.
- Which machine details your instance will match a condition against, so a question about the fleet is asked in terms it recognises rather than terms it quietly ignores.
- Clients and how the fleet is organisedWhich client each machine is attributed to, and the folder structure the fleet is arranged in — the two answers every per-client question rests on.3skills
Client attribution comes from the property set on each machine, so a machine nobody attributed belongs to no client until someone fixes it.
- The authoritative client list your machines are attributed to, read in one pass rather than tallied from the whole fleet.
- How the fleet is organised — the folders and smart groups machines are arranged into, and the rule that populates each one.
- What a client folder really holds — the rule that decides which machines land in it, so a folder's name is not taken for its contents.
- Who connected, and who was toldThe remote-access record: which technician reached which machine, at what time, from where, and what happened while they were in — alongside what this instance was set to record in the first place, and whether anybody hears about it when it happens.10skills
Reads the record only — it never joins, replays or alters a session, and an answer covers the window the last snapshot was able to read.
- Answer who connected to which machine and when — filterable by machine, by technician and by time window.
- Surface the commands technicians queued and ran over remote sessions — the least visible thing that happens during one.
- List the recordings held for one machine, with when each was taken and what triggered it — the index, never the recording itself.
- What this instance was set to record in the first place — the check that tells you whether a quiet stretch in the record was a quiet week or a blind spot.
- How many remote-access events fall inside a window — just the number, for sizing a review before anybody starts reading through it.
- How much remote-access history exists for a period, what each entry records and a short sample of it — enough to answer an auditor's scoping question before anything is handed over.
- The kinds of security event your own instance knows how to record — the vocabulary any question about the record has to be put in.
- The alerting rules configured on your instance and which of them are switched on — an instance with every rule turned off reads exactly like one with no rules at all.
- The rules that fire on remote access itself — whether anybody hears about it when a technician reaches a client machine.
- The language those alerting rules are written in, so a rule's condition can be read and judged rather than taken on trust.
- Who can get inEntitlement rather than activity: the people your instance would admit to a machine, whether or not any of them ever has — the roster they are drawn from, and the roles and account sources that decide it.4skills
Entitlement answers come from what the instance itself will tell us, so a roster or a per-person review covers the account sources that instance manages — read it as where a review starts, not where it ends.
- List the people entitled to remote into machines on your instance — the access review the connection record alone cannot answer.
- Every account your instance holds, including the ones that have connected to nothing — the roster an access review starts from, and the part an activity record cannot show you.
- Which machines one named person could reach — the access review in the direction it actually gets asked, when somebody leaves or a contractor's term ends.
- How access to your instance is governed — the roles defined on it, where its accounts come from, and what has been taken away again.
- The server, its licence and what it supportsWhat the instance itself is — the build it runs, whether ConnectWise hosts it or you do, how much of the licence is spoken for, and what it will answer for.3skills
These answers come from the instance itself, so an instance that does not report seat figures cannot be made to — the report says so rather than showing a zero.
- Report what your instance is running — the build it is on, and whether it is hosted for you or by you.
- Show how much of the remote-access licence is in use, and how much room is left before another machine cannot be brought under management.
- What your own instance supports, in its own words — what this connection can be asked for, which is not the same from one instance to the next.
How it has been taught to work it
Playbooks are the vetted techniques a session loads for this platform — what to check, in what order, and what a number means before it is reported.
- Automate ↔ ScreenConnect — which clients are missing which coverage"Which clients have Automate agents but no ScreenConnect (or vice versa)" — remote-access coverage gaps, reconciling managed endpoints against remote-access reach.Vetted Sep 21, 2026
- Querying ScreenConnect — the tools and their gotchasWhenever you actually call the ScreenConnect tools — the read surface, the arguments that matter, and the traps.Vetted Aug 31, 2026Always on
- ScreenConnect — access review (who can remote in + license headroom)"Who can remote in", eligible-host audits, license seat usage, or a combined access-review/QBR-shaped ScreenConnect question.
- ScreenConnect — command activity over remote sessions"What commands did techs run on machines" — command-execution visibility, security review of remote-session command activity.
- ScreenConnect — remote-access audit (who touched what)"Who remoted into this machine / this client, and when?" Security, compliance, or incident questions about remote access activity.Vetted Aug 9, 2026
- ScreenConnect — stale / outdated agentsFinding ScreenConnect machines with old agent versions, long-idle, or that have not checked in — remote-access hygiene.Vetted Aug 9, 2026
- ScreenConnect — unattended-access footprint per client"How many machines can we remote into for CLIENT?", coverage gaps, or a fleet-wide count of unattended ScreenConnect agents.Vetted Aug 9, 2026
- ScreenConnect (ConnectWise Control) — conceptsAny question about ScreenConnect — remote-access machines, who connected to what, unattended-access coverage. Read before querying so the session model and company mapping are clear.Vetted Aug 31, 2026Always on