Gravity Union

View Original

Why you should avoid folders in SharePoint

Many people love folders. Many people have grown up with them. Paper files, file folders, filing cabinets, filing rooms all give a straightforward and linear path to finding the right document. 

The folder model of organizing information transitioned itself nicely into the early days of the tech world. It’s still common today in how network drives are organized, and it’s how many people organize their personal drives and mailboxes.

There are a few challenges with the folder approach for organizing content that are worth noting – not the least of which is younger generations at work. Gen “Z” for example, have been raised on tablets, smartphones, social media and gaming, and have little familiarity with the folder/directory structure.  And in today’s work environment, the contexts and reasons for looking for information can vary greatly, so a fixed organization model and single linear path are not as effective as they were years ago.

In general, curators of SharePoint environments should avoid the use of folders in their solutions. Like all rules (many are meant to be broken), there are valid scenarios of when folders are acceptable, but they are far and few between. Sustainable SharePoint solutions with positive user experiences are built on the default position of minimizing folders; it should take a pretty good argument to include them in the solution.

Why are folders used so often?

Folders are intuitive for most. Their usage maps easily to real world organization of paper. If good titles are used, folders are easy to understand, and creating folders on laptops, networks, and OneDrive is simple enough for the average end user.

Folders allow us to bring together and organize related information. They help reduce the cognitive load while trying to find documents. They also help reduce the time and effort to find information by providing a navigable roadmap to it.

For example, this network drive path would make it very easy to find an invoice from Microsoft:

k:\Finance\Accounts Payable\Invoices\2022\May\Microsoft …

So, folders can organize describe our content, perhaps somewhat superficially, in two ways:

  1. Including ownership in the folder structure, like department\function\activity, makes it clear who owns the documents, who likely controls access and security, and provides a high-level location for documents that tends not to change over time, except for organizational restructuring.

  2. Including metadata in the folder structure, like 2022\May\Microsoft, which adds additional context for the content and provides a precise location, but necessitates ongoing folder creation as, in this example, the year, month and vendor changes.

Many end users may express a preference for folders over metadata — so what’s the problem then?

You could migrate the network drive folder structure into SharePoint

It’s certainly possible to move the folder metaphor to SharePoint to structure and store content.

In this example againFinance\Accounts Payable\Invoices\2022\May\Microsoft:

  • Finance would likely become a Site Collection (now simply known as Sites) and probably designated as a Hub Site.

  • Accounts Payable would become another SharePoint site and associate itself to the Finance Hub Site.

  • Invoices would become a document library

So, the structure in SharePoint might look something like the following:

https://CompanyName.SharePoint.Com/Finance/Accounts Payable/Invoices

Now comes the fun part – what to do with those descriptive folders?

We can either keep them as folders or promote those folders to metadata (i.e. site columns).

Now, it would be easy to move the folders/structure directly into the SharePoint library. After all, it’s likely how users are currently working, and maintaining the folder structure is easier to implement and familiar.

This is an approach taken by many organizations when migrating content from network drives and other sources into SharePoint.  But imagine for a moment the volume of potential folders across an entire organization — its many functions, departments, business lines and workgroups and activities.

In SharePoint, organizing content using a high volume of folders with deep folder structures has downsides. It’s:

  • Harder to govern

  • Creates a less than optimal user experience

  • Increases maintenance costs over time

  • Limits the return on investment (ROI) on Microsoft 365

Let’s discuss these pitfalls of folders in detail.

I. It’s harder to govern

With folders enabled in a document library, end users are free to create any folder they wish. This usually leads to misspellings (like “Micrusoft” or “Mikerowsoft”) and the creation of deep, nested folder structures that may make sense for the creator and close colleagues, but not for others.

Looking at how people organize their mailboxes, and how network drives are organized across an organization, illustrates the diversity of views on organizing information. And looking at these examples, there is never a shortage of empty folders, or folders with a single file because someone thought it was a good idea.

From a governance perspective, folders:

  • Decrease our ability to ensure consistency across document libraries (different spellings) and;

  • Decrease our ability to ensure consistency within document libraries (mixed metaphors at the same level of the folder structure)

If we have mixed metaphors, then the system is more difficult to understand and document library views are more difficult to create.

If we compare that to say using a managed metadata term set which lists our vendors, then:

  • We ensure that documents tagged with “Microsoft” get tagged with the properly spelled version of the company’s name

  • We ensure that people only select from the list of current valid vendors (no mixed metaphors) i.e. Vacation Photos will not appear in the list of vendors

  • We ensure that other document libraries in SharePoint that also need to tag documents with company names will have the same spelling

  • We ensure that if “Microsoft” can also appear in a list of Clients, or a list of Partners, or a list of Competitors 

Using managed metadata within content types improves the findability and searchability of content, and the future governance of the solution.

II. It creates a less optimal user experience

If a folder name (like “Microsoft”) is mis-spelled, and someone is searching based on that name they will likely not find what they are looking for — especially if file naming conventions aren’t consistent or thought through.

Search is critical for a great end user experience. It reduces the time to find content, reduces time spent recreating content, and leads to better decision making based on correct and up-to-date information.  Search is also a foundational for effective application of records management, eDiscovery, privacy and so on.

Deep folder structures in SharePoint create very long URLs.  But the URL field (column type) in SharePoint has a 255-character limit so if someone pastes a URL longer than that in a URL field, it will be truncated, and the link won’t work.  In general, URLs have a maximum size limit of 2048. If a recent migration strategy was a lazy lift and shift into SharePoint, chances are this limit was exceeded if the originating folder hierarchy was too deep, thus creating more errors.  In both situations some form of re-work will be required, and results in a poor user experience.

And finally, from a usability perspective, don’t forget the navigable breadcrumb that is at the top of the page. The usability of this feature is dependent on the folder names making sense, and the ability to see the folder path in its entirety – which is not possible If the folder path is too long.

III. Increases maintenance costs

The use of folders increases maintenance costs for your SharePoint Online implementation in the following ways:

Maintaining and updating the folder names

In our earlier example of Finance\Accounts Payable\Invoices\2022\May\Microsoft, imagine Microsoft Is eventually purchased by Elon Musk and renamed to Muskrosoft.

Then, each folder with the name Microsoft in it would have to be found and renamed.  Depending on how often Microsoft appears in folder paths, that could be very labor intensive. As well, any time a URL using the original folder name was used, for example a link in a document, the link will be broken and will have to be replaced.

This all may require hours or more likely days or even weeks of effort to fix depending on how governance is set up, how decision making happens, and the complexity of folder structure.

If we compare this to a managed metadata solution described above, by changing the term in the Term Store, all documents will be updated with the new correct name, and easily completed in less than a minute.

Combining files from multiple folders

In another scenario related to the vendor example, imagine Microsoft buys Apple and acts as one company going forward. That might necessitate moving all the Apple documents from Apple folders to the Microsoft folders and could take hours or days of work depending on the number of folders and volume of content.

Again, compared to a managed metadata solution, we only need to combine terms so that all Apple and Microsoft tagged documents get updated with Microsoft term.

A metadata solution also ensures that users cannot, going forward, select Apple from the list of Vendors as it will no longer exist as an option. And don’t forget, if folder creation is allowed, users would still be free to create a new Apple folder.

Given the limitations of folders and the less-than-optimal user experience that folders create, in many cases we’ve seen organizations decide to redesign document libraries to properly include metadata and move away from folders. We also see organizations re-design their overall SharePoint architecture following a lazy lift and shift into SharePoint, which can be a long term, laborious process.

IV. Limits ROI of the Microsoft 365 platform

Be mindful of the organizational resources (staff and funding) to maintain folder structures, moving content around different locations and the cost to re-work ineffective information architectures. These resources won’t be available for other opportunities and high value activities that are presented in Microsoft 365.  

Time would be better spent integrating SharePoint with other applications, developing fit-for-purpose business automations and applications such as Power Apps, and bringing new Microsoft 365 capabilities to the organization. The investment in content types and metadata instead of folders also supports records management, privacy, eDiscovery, FOI, ATIP and other compliance-based functions within the organization.

Don’t underestimate the change challenge

Moving people away from folders is a big change challenge because folders are personal, and people love the stuff they create.

In our migration projects that move content from folder structures into SharePoint, we focus on increasing people’s comfort of the new solution over time. Incorporating training, coaching and migration support for a few hours every week will lead to a more usable and valuable SharePoint solution. Reach out if you are planning a migration from folders into a modern Microsoft 365 and SharePoint – we can help you with a plan to get started, or support the full end-to-end implementation.  

References

Chin, Monica. “File Not Found.” The Verge. September 22, 2021.

Why you typically need many content types.” Gravity Union. Retrieved January 24, 2023.

Leveraging content types in SharePoint ECM projects.” Gravity Union. Retrieved January 24, 2023.

The problems of ‘lift and shift’ from SharePoint on-premises to SharePoint Online.” Gravity Union. Retrieved January 24, 2023.

Introduction to managed metadata.” Microsoft Learn. Retrieved January 24, 2023.