Operational Visibility in SharePoint: The Power of Change Logs

Happy New Year!

Last month, I finally completed a major refactoring of the Commander Tool. The entire codebase is now in a second full pass of testing to ensure that all functionality, interface elements, and error-handling controls behave exactly as intended. While that milestone felt great to reach, I’ll be honest—it also came with a bit of burnout, compounded by the usual stresses that accompany the holiday season.

Rather than pushing straight through, I decided to take a short detour down memory lane and revisit a feature that has been sitting in the back of my mind since 2016: SharePoint Change Logs.

The Incident That Started It All

Back in 2016, I dealt with a situation that many SharePoint administrators dread. A user with Full Control permissions (thankfully not a Site Collection Administrator) accidentally removed permissions across an entire Site Collection. The result was immediate and severe - users were locked out, productivity stopped, and leadership wanted answers.

At the time, we were running SharePoint 2013 and had no specialized tooling in place. We had to rely entirely on SharePoint’s built-in Audit Logs. While the data was technically there, extracting meaningful answers from it was anything but straightforward. The logs were dense, ID-heavy, and largely undecipherable without significant manual effort. Identifying what happened took time; identifying who did it took longer; and restoring the environment from backups took even longer.

That incident sparked a question that stuck with me:

How could a tool retrieve low-level system data and interpret it in a way that makes sense to administrators—without requiring them to become forensic analysts?

At the time, I didn’t have the bandwidth to pursue the idea, so it was shelved. But it was never forgotten.

Change Logs vs. Audit Logs: Not the Same Thing

Fast forward to today. I’m actively implementing a Change Log Reporting system within the Commander Tool—and achieving a level of success I honestly didn’t expect when I started.

First, an important clarification: Change Logs are not the same as Audit Logs, and they are not meant to replace them.

• Change Logs record that something happened and when it happened. They capture structural or content-level changes across sites, webs, lists, items, files, permissions, and other SharePoint objects. However, they:

  • Do not record who made the change

  • Retain only minimal metadata

  • Have a short retention window

  • Do not preserve deleted objects or their details once they are gone

    
    

  If a file is deleted, for example, the Change Log can tell you that a deletion occurred—but not the file’s contents, its metadata, or the user responsible.

  
  

• Audit Logs, on the other hand, are far more comprehensive. They can capture user identity, operation context, and richer detail—and they can retain that data for much longer periods. The tradeoff is complexity. Audit Logs require more configuration, deeper analysis, and typically align better with enterprise-grade governance and compliance platforms like Microsoft Purview.

  
  

Because of that complexity, Audit Logs fall outside the scope of what I want the Commander Tool to manage directly.

So Why Build a Change Log Reporting System?

The value lies in speed, visibility, and practicality.

A Change Log Reporting system acts as a first line of insight. It allows administrators to quickly answer questions like:

• What changed in my environment recently?

• Did something happen at the site, web, list, item, or file level?

• Are there unusual spikes in activity that warrant deeper investigation?

  
  

Instead of immediately jumping into a heavyweight auditing or compliance platform, an administrator can use Change Logs to narrow the scope of the issue. In many cases, that’s enough to resolve concerns without escalating further. When it’s not, Change Logs provide valuable context that helps guide more advanced investigations using tools like Purview.

In short, Change Logs are complementary, not competitive. They reduce noise, accelerate triage, and give administrators situational awareness they often lack in day-to-day operations.

Looking Ahead

I’m genuinely excited about this new capability in the Commander Tool. It’s still a work in progress—especially on the UI and reporting experience—but the foundation is solid, and the potential is significant. More importantly, revisiting this long-standing idea has helped re-energize me after an intense development and testing cycle.

I’m hopeful that finishing this feature will not only strengthen the Commander Tool, but also help shake off the remaining burnout as I wrap up testing across the rest of the platform.

Thanks for taking the time to read this update—and once again,

Happy New Year!