PowerShell Scanner

The #1 most requested feature

When admins moved from D&I to Connect, they lost access to their PowerShell scripts. Workflows they had built over years suddenly needed workarounds. The frustration showed up everywhere: support tickets, forums, Discord threads. It was the most requested feature for years.

Left behind when we moved to the cloud

This is the original scanner, a Windows desktop dialog that IT admins had used for over a decade. When we first talked about bringing it to Connect, it seemed straightforward. We'd rebuild the UI, match the functionality, and ship it. We had no idea how complex it would turn out to be.

Three problems we had to solve

Our first designs looked like a natural evolution of the original. When we tested early, the feedback was consistent: "This is exactly what we expected." But when we brought those designs to engineering, three problems emerged that changed everything.

• It required PowerShell knowledge, and in Connect, mistakes had real consequences. A bad script could run across an entire fleet with no guardrails.
• Scripts could run unconstrained. One heavy scan across thousands of devices could slow the system for everyone and spike infrastructure costs.
• The output was unpredictable. If data types were assigned incorrectly, users couldn't filter or act on their data, and would likely give up on the scanner entirely.

To make it even more interesting: we had two weeks to solve all of this before engineering needed to start building.

I had to become the user

To design for someone who doesn't know PowerShell, I needed to know it first. So before any mockups, I learned the foundations: how it works, how people use it, and where beginners get stuck. I documented what confused me, what clicked, and where things finally made sense. That turned into a beginner's guide I shared with the team. It shaped every design decision I made after that.

Going straight to the source

I needed user input, so I went straight PDQ's active Discord server to get in touch with users. Within two weeks, I scheduled over seven calls and since I didn't have prototypes yet, their feedback helped me iterate in between sessions. They were the right people to pressure-test it because they knew the old scanner inside and out, and they weren't shy about telling us when something felt off.

Making PowerShell approachable

A blank code editor is intimidating if you've never written a script before, so I built two things into the UI to help close the gap.

• Placeholder text inside the editor showing exactly what format the script output needed to be in, so admins had a working example from day one.
• A full code editor instead of a plain input field, with syntax highlighting and real-time error feedback so admins could catch mistakes as they typed, not after testing it on hundreds of devices.

Making sense of infinite output

The original scanner output exactly what the user wrote, right or wrong. This was a common complaint since users were spending more time troubleshooting script than managing their devices. To solve this, we forced users to test their scanner on one device and assign data types to each column their script returned. We were worried users would be frustrated at the extra steps, but it became one of the most loved parts of the design, and people said they wished the original scanner had it.

Scanners as a fleet superpower

The 3-step workflow solved the system strain problem too. Scripts don't run on all devices until the user validates the output, which eliminates the risk of a bad script overloading servers. Once validated, scanner data becomes a filter condition for devices and can trigger automations across Connect. For example: check BitLocker status -> group every at-risk device -> deploy a fix -> automate it going forward.