Rebuilding the Commander Tool for SharePoint Online: A Development Journey

It has been a while since my last update. Most of my time has been spent deep in the overhaul of the Commander Tool—an effort far bigger than I originally anticipated. While I’m not quite finished, I’m finally seeing light at the end of the tunnel, and I wanted to share the story behind what has changed, why it had to change, and where things are heading.

The Backstory: When SharePoint Online Broke Everything

In September 2025, I found myself wrestling with a big question:

How do I bring the Commander Tool forward into the modern SharePoint Online world?

I explored two obvious paths—Power Platform and SPFx—but neither solution aligned with what Commander needed to be:

• Power Platform could support a lightweight version, but not the full depth and modularity of Commander. Distribution would also be an ongoing challenge.

• SPFx initially seemed promising. I assumed I could reuse most of my existing code with minimal adjustments. That assumption… did not survive contact with reality.

  
  

Setting up SPFx was far from effortless, and maintaining distribution flexibility across environments would still be problematic. More importantly, neither approach gave me a clean or scalable way to preserve the modular architecture that Commander has relied on since its inception.

So I tested the existing Commander Tool directly against SharePoint Online. I wasn’t shocked that it didn’t work—only half surprised. SharePoint Online had quietly moved on, introducing restrictions that effectively shut out third-party code running directly in the browser. Not exactly ideal for a product built on CSOM client context.

Realizing how fundamental this break was, I updated the Commander Tool website to indicate support for On-Premises only.

But in the back of my mind, I knew this wasn’t the end of the story.

The Opportunity Hidden Inside the Problem

SharePoint’s architecture underpins OneDrive, Teams, and SharePoint Online itself. And Microsoft almost never truly removes features—they disable them, hide them, or wrap them, but rarely delete them.

This was important, because the Commander Tool’s foundation had always been CSOM client context. While still present in SharePoint Online, it is only accessible to code hosted on SharePoint itself, and SharePoint Online is notoriously unfriendly to custom inline JavaScript.

In other words: the house was still standing, but all the doors were locked.

The way forward became clear: move fully to RESTful data queries.

At first, SharePoint REST documentation was sparse and mostly static. But the REST API itself was rich—extremely rich. This led me to build a new piece of intellectual property: the REST Explorer, a tool that dynamically maps SharePoint REST endpoints through their metadata. Its insight became the key to refactoring Commander.

One revelation stood out: Microsoft exposes its REST architecture in a more detailed, navigable way than most platforms—allowing API discovery directly through metadata. This significantly accelerated the process of translating client context calls into REST.

The Other Major Challenge: Authentication in SharePoint Online

Shifting from CSOM to REST was only half the battle. Authentication posed a new hurdle.

Historically, Commander lived on SharePoint servers. It used built-in user credentials and never had to manage authentication explicitly. But REST—especially in SharePoint Online—requires proper Authorization headers.

Two problems emerged:

1. There is no “15 Hive” equivalent in SharePoint Online. I needed a new place to host Commander.

2. SharePoint Online relies entirely on Azure MSAL authentication. NTLM no longer applies.

   
   

The first problem solved itself once I fully embraced the reality that SharePoint Online sits inside Azure. Azure effectively became the “new 15 Hive.”

The second was more interesting. MSAL authentication is required, constantly evolving, and usually delivered via Microsoft’s hosted scripts. To preserve Commander’s non-SaaS model, I needed MSAL available locally.

After careful testing, I determined I could safely incorporate Microsoft’s MSAL.js directly into Commander—ensuring compatibility without depending on external hosting. With that, REST calls could be properly authenticated without compromising distribution or offline deployment.

Modernizing Commander: Design, Architecture, and Cross-Environment Support

Once I committed to this major refactor, I realized it was also the perfect moment to modernize Commander’s interface and user experience. The original UI served its purpose well, but it was starting to feel dated. So I redesigned as I rebuilt.

From a technical perspective, maintaining full compatibility with On-Premises environments remained a priority. Thankfully, REST is flexible enough to bridge SPO and legacy versions—though authentication differs dramatically (MSAL vs. NTLM). Commander now includes logic to detect the environment and adapt accordingly.

This naturally raises questions like: “Can I use Commander across SharePoint Online and SharePoint 2019 simultaneously?”

My current answer: I’m working on it.

Of course, REST has its limitations—especially when retrieving deep metadata that CSOM exposes more cleanly. For this reason, some differences will inevitably exist between Commander’s capabilities in Online vs. On-Prem environments. My goal is to minimize these differences, but transparency matters.

Introducing the New “Admin Center” (formerly the Developer Package)

I recently completed the refactoring of the Developer Package and decided it was time for a rebrand. The new Admin Center gives developers and administrators a third option beyond Power Platform and SPFx when working in SharePoint Online.

The Admin Center allows developers to:

• Deploy Commander to specific site collections

• Enable or disable individual modules

• Build custom modules that apply only to the current site collection

• Avoid platform limitations and red tape that typically accompany SPFx development

  
  

It’s still scoped to Commander, but it lays the foundation for much broader capabilities in the future.

Closing Thoughts

I’m now nearing the end of the initial development cycle. Every component has been refactored from client context to REST. I’m methodically validating modules, repairing code where needed, and adding new functionality to support SharePoint Online, such as hooks for Power Automate workflows.

Once the SharePoint Online build is stable, I’ll test everything again in my On-Premises environments—2013, 2016, 2019, and SE—to ensure full cross-version reliability.

After validation and fresh documentation of the installation process, I’ll announce the updated Commander Tool for distribution.

Thank you to everyone who has been following this journey. This phase has been months in the making, and I’m excited to finally share the results.