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!

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: There is no “15 Hive” equivalent in SharePoint Online. I needed a new place to host Commander. 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.

Lists are, hands down, one of the most powerful features of SharePoint. As both an administrator and a developer, I often prefer lists over libraries. From a technical perspective, lists and libraries are almost interchangeable—both store items, both support metadata, and both integrate with views and workflows. But if you’ve ever worked extensively with lists, you’ve probably encountered one of the biggest frustrations: field (column) creation and management. The Pain of List Field Management Through the native SharePoint interface, list field creation is a time-consuming process. Using List Settings  – You’re forced into a multi-step process: navigate to settings, select Create Column , configure properties, save, and repeat… for every single field. Using Quick Add via Headers  – While you can add simple columns directly from the list view, this approach still requires multiple clicks, and it lacks flexibility for more advanced field types. Microsoft’s own documentation confirms that column creation is intentionally designed to be “one at a time”: Validated Context: How SharePoint Handles Column Creation “To add a column to a list or library, select Add column  … Configure your options and select Save . Repeat this process for each additional column you want to create.”— Microsoft, Add a column to a list or library  (2024) Source For small lists, this is acceptable. But for any enterprise scenario —migrations, structured metadata implementations, or solution development—managing fields this way quickly becomes inefficient. How the Commander Tool Solves This The Commander Tool removes these bottlenecks by introducing bulk field management : Bulk Field Creation Modal  – Instead of creating fields one-by-one, you can enter an entire set of field names and configure types in a single session. CSV Import  – If you have a file with all the fields defined, Commander lets you import it and assign field types on the fly. Bulk Export & Import  – Field definitions can be exported for reuse across environments or imported to instantly replicate configurations. Full Range of Types  – Every standard SharePoint column type is supported, including text, choice, number, lookup, date/time, and more. Bulk processing isn’t an afterthought—it’s a cornerstone of the Commander Tool’s design. Why This Matters In practice, this capability changes how administrators and developers work: Rapid Prototyping  – Define all list fields up front and spin up working prototypes in minutes, not hours. Migrations – Move list structures between sites or farms with confidence and repeatability. Consistency – Reduce human error by leveraging predefined CSV files or templates. Scalability – Whether you’re defining 5 fields or 50, the process takes the same streamlined path. Closing Thought SharePoint lists are powerful, but Microsoft’s out-of-the-box experience for field creation is still very manual. With the Commander Tool, you can work smarter—building, scaling, and managing lists with bulk precision  rather than repetitive clicks.

Ever get that dreaded call? “I accidentally deleted something in SharePoint—can you retrieve it?” If the mistake was made today , restoring is usually straightforward. But if it happened days—or even weeks—ago, recovery becomes a frustrating obstacle course. How SharePoint Handles Deletions SharePoint doesn’t really delete  items in the traditional sense. Instead, it uses a flagging mechanism  to keep deleted items in place, unless they’re purged: First-stage (end-user) Recycle Bin : Items remain visible here for users to restore. Second-stage (site-collection) Recycle Bin : When first-stage items are removed, they end up here—only accessible by admins. Deleted content stays in these Recycle Bins for 93 days total in SharePoint Online , unless retention policies or quotas intervene. In SharePoint on-premises, the default is generally shorter unless customized. Importantly, the Recycle Bin content is not indexed  and thus invisible to eDiscovery or search. Microsoft Learn Why the Native Recycle Bin Falls Short As SharePoint environments grow, the Recycle Bin becomes unwieldy, exposing several critical limitations: No search capability . Users can't search for deleted items by name or metadata — they must manually scan pages. Microsoft Learn+1 Filtering is weak . While sorting may be possible, filtering by date, file type, or user isn’t supported. Microsoft Support Pagination is cumbersome . Large Recycle Bins—with thousands of items—force users to click endlessly through page after page. Worse—for high-activity sites, Recycle Bin items count toward list thresholds like the 5,000-item limit, further limiting view performance until purged. Power BI Community These translate into real, measurable pain: Recovering an item when you’re not sure of the deletion date? Hours of sifting. Admins forced to guess where files came from—or if they're even in scope. Compliance audits slowed because key artifacts are buried in poor interfaces. Commander Tool: Your Recycle Bin, Reimagined Say goodbye to manual paging and guesswork. The Commander Tool  turns the Recycle Bin from a frustrating limitation into a powerful, intuitive recovery workspace: Search at scale : Find deleted items by name or metadata—instantly. Filter and sort : Narrow results by user, date, file type, or original library. Full context : See where each item was deleted from, with path info—no more guessing. Bulk operations : Restore or permanently delete large sets of items in one streamlined action. Storage visibility : Review bin contents, storage impact, and important deletions without page-by-page slogging. Why It Matters Efficiency : Admins reclaim hours that were once spent digging through clunky UI. Accuracy : Reduced risk of overlooking needs or permanently losing items. User trust : Faster recoveries mean less frustration for end users. Governance : Better visibility supports compliance and content lifecycle management. When deletion isn’t a simple undo, having real tools matters. With Commander, your Recycle Bin becomes not just a safety net—but an intelligent part of your governance ecosystem.

Features are the building blocks of SharePoint — whether a site is created via out-of-the-box prefab configurations or you've layered in custom Features and scripts. They’re powerful… until they disappear—or get misconfigured—and leave you guessing: What do I actually have? I’ve experienced it plenty of times: Orphaned Features —those defined but not scoped properly—linger in the system, especially after migrations or updates. SharePoint doesn’t make it easy to list what’s installed, enabled, or orphaned. Using PowerShell like Get-SPFeature helps, but running and interpreting those scripts across a farm is time-consuming and error-prone. In both SharePoint Online and on-premises , administrators often don’t have a clear, visual report of what Features are in play—nor which ones might be unsupported or orphaned. How SharePoint Manages Features In SharePoint Server , you can use Get-SPFeature (optionally with parameters like -Site, -Web, -WebApplication, or -Farm) to list activated [ Features. Microsoft Learn ] Administrators often use PowerShell scripts to generate environment-wide Features reports—grouped by scope, display name, and more. [ SharePoint Diary The Frog Pond of Technology ] Orphaned Features, which have no defined Scope, can be listed with Get-SPFeature | where { $_.Scope -eq $null }, and potentially cleaned up—though caution is advised. [ bits and bytes SharePoint Stack Exchange ] In SharePoint Online , administrators can use CSOM-based PowerShell (via ClientContext) or the Get-PnPFeature command to list site and web scoped Features. [ SharePoint Diary ] But still, these require scripting fluency and cross-environment checks. There’s no out-of-the-box UI that tells you everything clearly. How the Commander Tool Solves the “Feature” Blind Spot How Commander delivers major value: Unified feature visibility : See every Feature available, enabled, or disabled at both Site (collection) and Web levels—without running scripts or parsing logs. Legitimacy reference : Commander ships with a prebuilt inventory from a standard SharePoint 2013 farm. This gives you a baseline to spot unexpected or custom Features that may need validation. Inventory updates for newer farms : For environments beyond SP2013, Commander provides the required PowerShell script and clear instructions so you can refresh and align your baseline. Easy control : Enable or disable Features with a simple switch inside the dashboard—no deep-diving into Site Settings or Central Admin. Orphan detection : Instantly spot orphaned or unsupported Features that never clean themselves up, potentially surfacing upgrade risks before they become serious. Why This Matters Clean governance : Knowing which Features are active, where they originated, and whether they’re valid helps you reduce upgrade and compliance headaches. Risk reduction : Orphaned or rogue Features can break site behavior or even block upgrades. Flagging them early helps avoid major disruptions—especially in on-prem farms approaching end-of-life cycles. Operational clarity : Instead of running custom PowerShell scripts or hunting through Central Admin, administrators get one place for feature oversight—so you can act fast. In short:  Features should empower your SharePoint environment, not mystify it. With Commander’s Feature management capabilities, you gain clarity and control—without complicated scripting.

Workflows are supposed to make SharePoint easier. They automate approvals, move documents along, and save your team from manual busywork. But anyone who has lived with SharePoint for more than a few months knows the truth: workflows can just as easily become a source of frustration. In both on-premises SharePoint  and Microsoft 365 , tasks and workflows are executed via a complex background timer system. And when things go wrong, they go really wrong. I’ve seen it firsthand: Workflows that never complete because an instance gets “stuck” in In Progress mode. Multiple versions of the same workflow spinning endlessly in the background for months. A growing backlog of failed or frozen tasks, clogging the system and confusing users. No clear way to figure out which items  those stuck workflows are tied to, leaving you chasing ghosts. The result? Wasted time, frustrated users, and processes that everyone stops trusting. Where SharePoint Falls Short The real pain isn’t just the failures—it’s the visibility. Native SharePoint gives you very little insight into: Which workflows exist in a given web or site. Which lists those workflows are connected to. Where the “stuck” instances actually live. Administrators are left sifting through logs and item histories, trying to match instances to the right content. It’s slow, clunky, and sometimes impossible to fully resolve. How the Commander Tool Helps This is where the Commander Tool  changes the game—at least for on-premises SharePoint (Power Automate support is on our roadmap). With Commander, you can: See all workflows that exist for a web in a single dashboard. Quickly identify which lists and libraries those workflows belong to. Enable or disable workflows with just a click—no digging through site settings. Discover every “stuck” workflow instance and immediately see which item it’s tied to. Stop broken or looping instances on the spot, before they drag on for weeks or months. Instead of chasing invisible errors, you get clear, actionable visibility . What was once a black box becomes a manageable part of your SharePoint environment. Why This Matters When workflows are reliable, users trust them. When they’re not, adoption suffers. By giving admins the tools to untangle messy or broken workflows, Commander helps restore confidence in the processes that should be making life easier. SharePoint workflows don’t have to be the bane of your existence. With the right visibility and control, they can finally do what they were designed to do: save time, not waste it.

One of the most common headaches in SharePoint administration is sprawl . What starts as a well-structured environment—clean site collections, clear hierarchy, sensible permissions—often devolves into a tangle of abandoned sites, redundant libraries, and confusing permissions structures. I’ve seen this play out in many environments. A new project team spins up a site. A department head requests their own collection. Someone discovers “Create Site” and before long, the environment looks like an uncharted wilderness. The real problem  isn’t just the number of sites—it’s that no one can easily tell: Which sites are still in use Who owns them Whether the content is relevant or outdated What permissions have drifted away from policy Both SharePoint Online  and on-premises environments suffer here. Online tenants often balloon because self-service site creation is so easy. On-prem farms accumulate sites across years of upgrades and reorganizations. In both cases, sprawl erodes productivity, creates risk, and makes governance feel impossible. Traditional Attempts at Controlling Sprawl Manual Inventory Audits : IT teams often attempt to document sites manually or keep spreadsheets. This is immediately outdated the moment someone creates a new site or abandons an old one. Restricting Site Creation : While locking down who can create sites sounds good, it often slows down business and leads to shadow IT as employees go outside SharePoint for collaboration. Periodic Clean-ups : Administrators try to run usage reports or PowerShell scripts. In Online, this might mean exporting activity logs. In on-prem, it might mean querying the content databases or running health/usage collection. Both are brittle and resource-intensive. How the Commander Tool Cuts Through Sprawl This is where the Commander Tool  makes a difference. Instead of relying on piecemeal scripts or guesswork, Commander provides a real-time map of your entire SharePoint environment —whether cloud, on-premises, or hybrid. With Commander, you can: Instantly discover every site, subsite, and collection —including long-abandoned ones. See usage patterns at a glance : Commander highlights which sites are active and which are dormant. Identify site owners  so you know who to contact about cleanup or lifecycle decisions. Enforce best practices : Quickly surface sites that are missing metadata, following broken naming conventions, or diverging from governance rules. Instead of spending hours (or days) crawling through logs or begging users to tell you which URLs they care about, Commander lets you take control in minutes. Final Thought SharePoint sprawl will always be a natural byproduct of collaboration—it’s proof that people are using the platform. The challenge is channeling that growth into something manageable and sustainable . With the Commander Tool, sprawl stops being a nightmare and becomes just another part of a healthy governance routine.

If permissions are the number one source of SharePoint frustration, metadata is a close second. It’s the backbone of findability and governance, yet in most environments—whether SharePoint Online or on-premises—it’s inconsistent, misunderstood, or simply ignored. I’ve walked into environments where some libraries have beautifully designed content types and metadata columns, while others rely entirely on folder sprawl. Users upload documents with no tags at all, or worse, make up their own inconsistent values. Over time, the system that was supposed to make information easier  to find becomes a barrier instead. How Metadata Gets Messy Across environments, the same patterns keep surfacing: Too many custom columns - Well-meaning admins create dozens of one-off columns that overlap or duplicate values. No governance for content types - Content types are powerful, but unmanaged ones quickly multiply and lose consistency. Reliance on folders instead of metadata - Old habits die hard—users stick with nested folder structures instead of applying metadata filters. Incomplete or inconsistent tagging - Without required fields or automation, metadata entry becomes optional and quickly degrades. Search that doesn’t deliver - When metadata is inconsistent, SharePoint’s powerful search features—refiners, managed properties, queries—can’t live up to their potential. The result? A system that looks structured from the outside, but collapses under pressure when users try to find the information they need. Best Practices That Work (In Theory) There’s no shortage of best practices for metadata management, and they apply equally whether you’re running in Microsoft 365 or on-premises: Plan content types centrally : Establish reusable, standardized content types for key business documents. Limit custom columns : Use global term stores or site columns where possible to prevent duplication. Make metadata required—selectively : Strike a balance between enforcing tagging and avoiding user fatigue. Educate users : Metadata only works when people know why  it matters and how it makes their lives easier. Align with search : Ensure that the metadata you capture maps to refiners, filters, and search-driven experiences. But here’s the problem: even with strong governance, without the right visibility, administrators and knowledge managers are flying blind. How the Commander Tool Clears the Clutter This is where the Commander Tool proves its value. Instead of piecing together reports from different site collections or scripting one-off audits, Commander provides a unified, real-time view of your metadata landscape. With Commander, you can: Instantly see how metadata is applied across libraries, lists, and sites. Identify columns and content types that are redundant or unused. Highlight libraries relying heavily on folder depth instead of metadata. Provide actionable insights to owners on where metadata gaps exist and how to fix them. For admins, this means fewer “I can’t find it” help desk calls. For knowledge managers, it means cleaner, more reliable data for search and reporting. And for end users, it means a SharePoint environment that finally delivers on the promise of findability .

One of the most common headaches in any SharePoint environment is permissions. Step into a mature deployment—whether it’s SharePoint Online  or a farm running 2016/2019 —and you’ll quickly realize how tangled things can become. Over the years, I’ve walked into environments where permissions were applied at every imaginable level: site collections, subsites, lists, libraries, folders, and even individual items . Add in well-intentioned but inconsistent practices—like granting direct user access instead of using groups —and suddenly you have a permissions landscape that no one fully understands. The impact is real: Users are confused about why they can’t access something they believe they should. Business units create “shadow sites” to bypass roadblocks. Security teams worry about oversharing sensitive data. Administrators spend hours chasing down why a certain person can’t see a file or why a sensitive library is suddenly visible to far too many people. Why Permissions Get Out of Hand A few consistent patterns show up regardless of whether you’re dealing with SharePoint Server  or Microsoft 365 : Broken inheritance everywhere : Breaking inheritance has its place, but when it happens at multiple layers (library, folder, item), auditing or maintaining permissions becomes nearly impossible Microsoft Learn, Understand Permission Levels in SharePoint. Direct user permissions instead of groups : SharePoint thrives on group-based security . Adding individuals directly may solve an immediate problem, but it creates long-term sprawl Microsoft Learn, Plan permissions in SharePoint. Orphaned and abandoned sites : Sites without clear ownership often linger with outdated permissions, creating security and compliance risks. Lack of visibility : SharePoint’s native interfaces—whether Central Administration, Admin Center, or PowerShell—don’t make it easy to visualize permissions holistically . Admins are left running ad hoc scripts or clicking through endless settings pages Microsoft Docs, Check user permissions. Best Practices That Help (But Rarely Solve It All) There are established ways to rein in permission chaos, and they apply across environments: Standardize governance : Define where inheritance should remain intact and where exceptions are allowed. Favor groups over individuals : Manage access through SharePoint groups or AD/M365 groups  for sustainability. Review permissions regularly : Conduct periodic audits of access reports, whether through usage analytics, Admin Center, or PowerShell exports. Reinforce ownership : Assign and confirm site owners who are accountable for keeping permissions in check. These practices work, but in reality, they’re hard to maintain without full visibility  into the entire environment. How the Commander Tool Cuts Through the Noise This is where the Commander Tool changes the game . Instead of piecing together reports or interpreting cryptic PowerShell outputs, Commander gives administrators and knowledge managers a unified, real-time view of permissions across all sites . With Commander, you can: Instantly identify where inheritance is broken  and at what level. See which users have direct access versus group-based permissions . Highlight abandoned or underused sites  with lingering permissions. Provide actionable, visual reports  to site owners so they can clean up confidently. In practice, this means: Fewer “Why can’t I get in?” tickets. Fewer “Who gave them access?” surprises. A stronger overall security posture  for your SharePoint environment. Whether your organization is cloud-first or still maintaining on-premises farms, Commander simplifies what has historically been one of SharePoint’s biggest pain points , making permissions management transparent, actionable, and sustainable. References: Microsoft Learn. Understand Permission Levels in SharePoint.   https://learn.microsoft.com/en-us/sharepoint/understanding-permission-levels Microsoft Learn. Plan permissions in SharePoint.   https://learn.microsoft.com/en-us/sharepoint/plan-site-collection-permissions Microsoft Docs. Check user permissions in SharePoint.   https://learn.microsoft.com/en-us/sharepoint/understanding-permission-levels#check-user-permissions

The Pain (from personal experience) Joining a new SharePoint environment often feels like exploring in the dark. There’s no documentation. Only a handful of “official” sites are on the radar, while dozens—sometimes hundreds—of well-intentioned but mismanaged sites hide in the shadows. Sometimes someone is available to guide you, but more often the knowledgeable person has already left, or no one was assigned at all. That leaves you stuck in awkward conversations like, “Who are you?” and “What’s the URL?”—burning hours just to get oriented. By implementing the Commander Tool , I gained clarity and confidence. I could immediately discover all client-related sites—active, abandoned, or forgotten. I could see which ones were actually in use, identify owners, and start troubleshooting almost instantly. Governance enforcement stopped being a guessing game and became part of my daily workflow. Why This Happens & Why It’s So Common SharePoint, whether running in Microsoft 365 or in a traditional server farm, makes site creation easy. That’s a strength for collaboration—but without governance, it creates sprawling environments filled with duplicates, abandoned pilots, and “temporary” project spaces that never get retired. Ownership often fades over time. User accounts are disabled, contractors roll off projects, and suddenly entire site collections have no active steward. Both in the cloud and on-prem, admins are left with “orphaned” sites that still store business content but lack accountability. Visibility is another challenge. The data to track site activity exists—through Admin Center usage reports, PowerShell commands like Get-SPOSite or Get-SPSite, or even SQL/health logs—but it’s scattered. Instead of a clear view, admins must stitch together exports, dashboards, and scripts, which makes it easy to miss inactive or risky sites. The Hidden Costs You Feel Efficiency Drain.  Hours wasted just finding the right URL or figuring out who owns a site. Missed Risk.  Abandoned or orphaned sites may still contain sensitive data—or worse, still allow access. Client Frustration.  Early delays erode trust when you can’t quickly answer “where is that site?” Governance Gaps.  Without visibility, naming conventions, ownership policies, and retention rules are impossible to enforce. Operational Bloat.  On-prem farms get weighed down with stale site collections and oversized content databases, while cloud tenants sprawl with unused groups and sites. A Practical Recovery Plan You Can Start This Week Inventory everything.  Run a complete site inventory using PowerShell (Get-SPOSite for tenants, Get-SPSite -Limit All for farms). Capture URL, owner, storage, and last modified date. Check activity.  Use Admin Center analytics or Graph API in Microsoft 365, or usage/health logs and SQL queries on-prem, to flag sites with no activity over your inactivity threshold (e.g., 6–12 months). Verify ownership.  Every site should have at least two active owners. Audit ownership fields and cross-check with Active Directory to ensure accounts are still valid. Take action on abandoned sites.  Archive, detach, or delete as appropriate. For cloud sites, apply expiration or retention policies; for farms, safely move unused sites into a dedicated archival content database before removal. Enforce governance from now on.  Use provisioning controls, naming standards, and expiration rules to prevent future sprawl—whether through automated provisioning policies in the cloud or scripted workflows in on-prem environments. How the Commander Tool Solves This Pain Instead of juggling PowerShell scripts, Admin Center dashboards, Central Admin pages, and SQL queries, Commander provides a single pane of glass  for both SharePoint Online and Server. Comprehensive site discovery.  Instantly finds every site—active, hidden, or orphaned—across the environment. Usage and activity at a glance.  Reveals usage patterns so you can see what’s active, dormant, or abandoned without parsing multiple reports. Ownership clarity.  Identifies sites lacking sufficient owners so you can resolve orphaned environments quickly. Faster troubleshooting.  With URLs, owners, and activity visible in one place, you can immediately begin resolving client issues. Governance enforcement.  Provides actionable insights on inconsistencies, stale sites, and underused spaces—making it possible to apply best practices across both cloud and server environments. Bottom line:  Whether you’re stepping into an overgrown Microsoft 365 tenant or a legacy SharePoint farm, the hardest part is not knowing what’s really out there. Commander turns that blind scramble into clear visibility, so you can walk into any environment and take control from day one.

I've been working with SharePoint for quite some time now—long enough to witness its awkward teenage years and subsequent transformations. I've experienced my fair share of frustrations and have been genuinely impressed by its flexibility. That’s why I refer to my relationship with SharePoint as a love/hate relationship . I appreciate its adaptability; it can be transformed into collaboration portals, document management systems, knowledge bases, and even workflow-driven business applications. However, I dislike that its functionality is often hidden beneath layers of menus, ribbons, and cryptic settings. SharePoint’s Interface Challenge Back in 2007, I thought SharePoint had made significant progress. Compared to its 2003 version, it felt modern and powerful. However, the more I worked with it, the more I realized that while the capability was there, finding it was another story . Microsoft tends to scatter essential functions across multiple screens or disable features based on version, licensing, or security settings. There were days when I would be deep into documentation and still couldn't locate the option I needed. Other times, I would unexpectedly discover a useful feature buried within the SharePoint structure. This inconsistency was quite frustrating. Reflecting on the SharePoint Designer Era One tool I found particularly useful was SharePoint Designer . While it wasn't flawless, it at least centralized many of the features that admins and developers needed. You could view site structures, workflows, and data connections—all in one place. When Microsoft decided to discontinue Designer, the gap became apparent. Suddenly, there was no single, consolidated view for power users, leaving me to piece together multiple interfaces to gain a complete understanding. Inspiration Behind the Commander Tool This frustration inspired me to create the Commander Tool . My goals were to: Consolidate the features I frequently use into a single interface. Reintroduce some of the familiarity and efficiency I enjoyed with Designer. Enhance SharePoint with entirely new functionalities that Microsoft never provided. The outcome is a tool that accomplishes what SharePoint itself has struggled with: offering a single, powerful, and easy-to-navigate interface that integrates site details, content management, permissions, and knowledge indicators all in one place. Final Thoughts My love/hate relationship with SharePoint remains unchanged. I still encounter its quirks, and I often find myself shaking my head when Microsoft hides something useful three clicks too deep. Instead of merely coping with these frustrations, I took action to bridge the gap —for myself and for others who share similar sentiments. Ultimately, the Commander Tool is the culmination of two decades of appreciating SharePoint’s potential while disliking its execution —and finally taking steps to address it.

Microsoft SharePoint is a powerful platform widely used by businesses for document management, collaboration, and content sharing. However, many organizations only scratch the surface of what SharePoint can do. There are numerous features that can significantly improve productivity, streamline workflows, and enhance communication, yet these capabilities often go underutilized. At SummitPoint , we help businesses unlock the full potential of SharePoint by identifying key features that deliver real value. Whether you’re new to SharePoint or looking to optimize your existing setup, understanding these underused tools can transform how your team works. 1. Version Control and Document History While most users save and update files, many don’t fully utilize SharePoint’s robust version control system. This feature tracks every change made to a document, allowing you to review or restore previous versions easily. Using version history helps prevent data loss, resolve conflicts, and maintain an audit trail, especially valuable in regulated industries or teams with frequent document collaboration. 2. Automated Workflows with Power Automate SharePoint works smoothly with Microsoft Power Automate, allowing businesses to automate repetitive tasks easily without any coding. Automated workflows can include: Document approval processes Notifications when files are updated Automatic archiving of outdated content Many organizations miss out on this feature, continuing manual processes that automation could streamline. 3. Custom Lists and Metadata Instead of relying on simple folders and filenames, SharePoint allows the creation of custom lists enriched with metadata fields. This helps categorize, filter, and find documents or data more efficiently. For example, a project management team might create lists tracking project status, deadlines, or assigned personnel, all searchable and sortable within SharePoint. 4. Secure External Sharing Sharing documents with clients, vendors, or partners is critical, but it needs to be secure. SharePoint’s external sharing features let you control who accesses files, how long they can view them, and what permissions they have. Businesses often overlook these granular controls and resort to less secure file-sharing alternatives. 5. Integration with Microsoft Teams Many companies now use Microsoft Teams for communication, but not everyone realizes how closely SharePoint integrates with Teams. Every team channel in Teams has a dedicated SharePoint site behind the scenes for file storage. Leveraging this integration means your files stay organized and accessible while conversations happen in real time, boosting collaboration without extra steps. 6. Personalized Content and Newsfeeds SharePoint can deliver personalized content experiences based on user roles, interests, or departments. The newsfeed and dashboard tools help keep employees updated with important announcements and relevant information. This enhances engagement and ensures teams stay aligned with company goals and initiatives. 7. Powerful Search Functionality SharePoint’s search capabilities go far beyond basic keyword lookups. Advanced search lets users filter by document type, author, date, metadata, and more. Custom search configurations can further tailor results to your business needs. Effective use of search saves time and reduces frustration, especially in large organizations with vast amounts of content. 8. Mobile Access and Responsiveness With more remote and mobile work than ever before, accessing SharePoint on smartphones and tablets is crucial. SharePoint’s mobile apps provide nearly full desktop functionality, allowing teams to review, edit, and collaborate on documents anytime, anywhere. Despite this, many companies fail to promote mobile adoption, missing out on increased flexibility and productivity. How SummitPoint Helps Businesses Harness SharePoint Features At SummitPoint, we specialize in helping organizations fully leverage SharePoint’s capabilities. We assess your current environment, identify gaps, and implement solutions tailored to your workflows and goals. From setting up automated workflows  to customizing metadata and enhancing security settings, our team ensures you get maximum value from your SharePoint investment. Making the Most of SharePoint Features To unlock these powerful SharePoint features, consider: Training teams on lesser-known tools and best practices Regularly reviewing your SharePoint setup for optimization opportunities Partnering with experts like SummitPoint for strategic guidance Encouraging feedback from users to tailor SharePoint to their needs These steps help transform SharePoint from a simple file repository into a dynamic collaboration platform. Unlocking Business Potential with SummitPoint and SharePoint Features Understanding and utilizing the full spectrum of SharePoint features can redefine how your business manages information and collaborates. From enhanced security to automated workflows and personalized content, these capabilities drive efficiency and engagement. By working with SummitPoint, you gain access to the expertise needed to harness SharePoint’s potential fully. Let us help you unlock hidden features that your team isn’t yet using but should be, taking your productivity and collaboration to the next level.