SharePoint at 25 – Episode 3: The Folder Myth — What Modern SharePoint Actually Needs

In this episode of the SharePoint at 25 series, I tackle one of the longest-running and most misunderstood debates in the SharePoint world: folders versus metadata.

For years, the conversation has been framed as a binary choice — either you use folders or you use metadata. But in reality, modern SharePoint environments require a much more balanced approach.

In this episode, I unpack where the debate originally came from, why folders made perfect sense in the file server era, and how SharePoint introduced a completely different way of structuring information through metadata. More importantly, I explain why the real problem was never folders themselves — it was expecting them to carry the entire information architecture of a system.

We also explore how the modern SharePoint library experience has evolved, with views, filtering, and metadata now sitting at the centre of how people interact with information. And with AI tools like Copilot entering the picture, structure and context are becoming even more important.

Rather than arguing for “no folders ever,” this episode presents a more practical design perspective:

• Folders provide containment
• Metadata provides meaning
• Views provide experience
• Design provides governance

When these elements work together, SharePoint environments scale. When they don’t, complexity builds — and AI tools will surface those problems very quickly.

If you’ve ever been in a workshop where the folders vs metadata debate spiralled out of control, this episode resets the conversation and explains how these pieces actually fit together in modern Microsoft 365 environments.

Links & Resources

Fix the Mess™ Training and Courses
 https://fixthemess.ai

Transcript

Welcome back to the SharePoint twenty fifth birthday series. In the last episode, we talked about something that most organizations still get wrong governance. And the main point I made was this governance isn't a document; it's not a PDF sitting in a SharePoint library that no one has opened since the steering committee signed it off three years ago. Governance is design. It's the set of structural decisions that quietly shape how work happens every day, and that governance includes things like naming conventions such as your site and library names. Site structure, permissions and metadata. All of these things influence behaviour far more than a governance document ever will. And that leads perfectly into today's topic. One of the longest running debates in SharePoint history. Folders versus metadata.

Now, if you've worked in SharePoint for any amount of time. You've heard this argument. Someone stands up in a workshop and says folders are bad. We shouldn't use folders. Metadata replaces folders. And then someone else says, but our users like folders. And the conversation spirals into philosophical debate that somehow still hasn't been resolved. Twenty-five years into Sharepoint's life. So today, I want to reset the conversation a bit because in my experience, the entire debate is framed incorrectly.

There's a narrative that has floated around the SharePoint community for years that Microsoft doesn't want you using folders anymore. The folders are somehow an outdated relic of the server era. But here's the reality. If Microsoft truly didn't want you to use folders, they wouldn't still exist. They wouldn't be a core component of document libraries, and they certainly wouldn't be used in many of Microsoft's own products and demonstrations. Folders are not the enemy folders are simply one tool. The real problem is when folders become the entire information architecture. And that's what we inherited from the file server era. Because on file servers, folders had to do everything. They carried the document type, status, department version lifecycle ownership, project structure all inside a single path. So, we ended up with structures like this project. Then phase document type status year final final final, final version two. Which worked until it didn't. Navigation broke. Permissions became impossible to track, and finding anything required you to know exactly where someone else decided to store it. Then SharePoint introduced something fundamentally different metadata.

Instead of forcing information into a single location, metadata lets you describe information. A document can be a policy owned by HR, part of a compliance program approved, created this year all at the same time without being buried inside a deep folder tree. And that's incredibly powerful because now you can surface the same content in multiple ways through views. One view might show documents grouped by document type, another might show active projects, another might show documents modified this week. Same library, different perspectives. Folders alone can't do that. And this is where people are often surprised by my position because I do use folders. I just don't use them as the intelligence layer. For example, if I'm designing a project library, I might create a top-level folder per project Y for containment. Users need boundaries. They need visual orientation. A long, flat list of documents across dozens of projects becomes messy very quickly. So, a shallow folder structure can help people understand where they are. But what I don't do is push classification down into six levels of folders, because the moment folders start carrying document type, life cycle status, retention signals, or approval status. They are doing the job that metadata is designed to do, and they do it poorly.

Now here's the part that might surprise people, because lately I've been hearing a new argument that with AI and copilot coming into the picture, folders should disappear completely. And I'm not convinced that's true either. Copilot doesn't browse folders the way humans do. That part is correct, but copilot absolutely uses context signals from the environment and folder structure is one of those signals. Let me give you an example. Imagine you have two environments an environment, a. Everything is stored in one massive document library with hundreds of thousands of files. No structure, minimal metadata, just search. In environment B documents sit inside shallow project folders. Metadata captures document type status and ownership permissions are clean. The architecture is predictable. Which environment do you think copilot will perform better in the second one? Because AI thrives on structure and context and folders can still provide contextual grouping. What copilot struggles with is deep, chaotic hierarchies, where meaning only exists in a long path name. That's not structure, that's just hidden metadata inside text strings. And if you look at how Microsoft has evolved SharePoint libraries, the direction is pretty clear. Views are now front and center. This filtering, grouping, metadata, columns, all of that is designed to give users different ways of interacting with information. But folders still exist alongside that because people still think spatially, they still need boundaries. And removing every folder doesn't magically make a system modern. It just makes it confusing. So here's the position I've landed on. After years of designing SharePoint environments. Folders provide containment metadata provides meaning. Views provide experience and design. Provides governance. With those four elements working together, the system scales when folders are expected to do everything. The environment eventually collapses under its own complexity. And interestingly, copilot will be the thing that exposes that complexity fastest. Because AI doesn't politely work around messy architecture, it amplifies it.

So, what does this mean for the next twenty-five years of SharePoint? So, SharePoint has just turned twenty-five, which means most organizations today are carrying layers of historical decisions. File server thinking, migration shortcuts, half implemented metadata models, deep folder trees that nobody wants to touch anymore. That's exactly why I started the Fix the Mess series, because governance isn't going to solve these problems. Another policy won't fix them. The only thing that fixes them is designing the system properly. In the next episode of the SharePoint twenty fifth birthday series, we're stepping outside the document library and into something that has quietly become the biggest structural influence in Microsoft three hundred sixty-five Microsoft Teams. Because every time someone clicks, create a team. Something very interesting happens. Underneath.

A team is created, a SharePoint site is provisioned, a document library appears, permissions are established, and structure is being generated. Often before anyone has thought about governance at all, which means the team's conversation is really a SharePoint architecture conversation in disguise. And that's where things get very interesting. If this episode resonated with you, the ideas we've talked about here are exactly what the Fix the Mess training series is built around practical design approaches that work in real environments, not theoretical governance frameworks. You'll find links to the Fix the Mess courses in the related blog posts in the show notes. Thanks for listening and I'll see you in the next episode.