0% found this document useful (0 votes)
23 views4 pages

Reasons Why Folders in Sharepoint Are A Bad Idea

Uploaded by

Dmitriy Savelyev
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
23 views4 pages

Reasons Why Folders in Sharepoint Are A Bad Idea

Uploaded by

Dmitriy Savelyev
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 4

1.

File duplication

Folders allow you to copy files and save them in different locations. Risky when
you do not want users to send around different versions of one document.

2. Data integrity

When users are allowed to create folders, it is likely that you will encounter data
integrity issues (e.g. misspelled company name or different spelling by leaving out
‘the’ in the name). This will cause loss of time searching for documents you think
have a different name and can even lead to duplications because users think the
document doesn’t exist, since it has a different name.

3. Sub-folders

Too many sub-folders tend to hide files, making it difficult and time-consuming to
find particular documents. It also complicates the structure of your documentation.

4. Difficult to change

A folder structure is static and thus very difficult to change while your
organization is constantly changing and evolving.

5. Sorting and filtering

A folder structure does not have the capabilities of filtering and sorting all the
files because they are split up in folders and sub-folders. Users can only filter
the particular folder they are in, sub-folders not included.

6. Usability

The only one who knows exactly how the nested folder structure is built up, is the
one who built it (e.g. users don’t know how many sub-folders a folder has, unless
they are very familiar with the structure).

7. One viewpoint

Folders only allow you to view the documents in that folder in one specific way,
the folder way. With metadata, on the other hand, you can create many different
kind of views based on the properties you have added to these documents (e.g.
organize by project, by customer, by date,…).

8. Limited URL’s in Sharepoint

Sharepoint adds the name of folders and sub-folders to the URLThe URL limit in
Sharepoint is 260 characters, so if you create too many sub-folders you might bump
into an issue.

9. No right place
This is the biggest issue and most easily understood; folders force you to put a
document or file in a single location, even if it might legitimately be associated
with several places. A project report could be put in a folder with all the other
documents for that project, or in a folder for reports, or in a folder for
documents that are archived; in reality it should be in all three but that creates
duplicates. SharePoint metadata would let you tag the document as being a Report,
associate it with a Project, set its status to Archived and more. Different views
would let you see (or hide) all Archive documents, all project reports, all
documents that are not in draft that have be modified by me in the last 7 days and
include the Technology tag, etcetera, etcetera. And you can switch between views
with a single click.

10. Usability
Unless you have a rigorous and actively managed file plan (and, let’s face it, no
one actually does this well) then the folder structure is only known to the
person/team who created it. Everyone else has to inefficiently browse the contents
hidden in the folders in the hope of finding the document or file.

11. URL length limitation


SharePoint Folders builds the URL using all folder and sub-folder. However the URL
length is limited to around 255 characters; beyond that you get an error. Deep
folder structures simply break in SharePoint.

12. Unfixed URL


Moving a file from one folder to another changes the file URL, so any fixed links
to it will break.

13. Security
You can use folders to define security for groups of files in SharePoint, however
ongoing management of this is as big an administrative nightmare as it is on file
servers.

14. User experience


The user experience (UX, navigation, finding the documents) is marginally worse
than it is on file servers – it’s slow, content is hidden until you open the
folder. Moving content within folders is terrible within the browser, navigating
between folders is horrible too. (though you can open the library in Windows
Explorer).

15. File duplication


Folders actively cause file duplication, partly because there is no one, right
place for a given document or file (in fact you often have to put a file in
multiple paces because folders are so inflexible), partly because you can’t see
that the file already exists elsewhere. If you are striving for a ‘single version
of the truth’ then creating duplicates immediately undermines this principle.

16. A single view


One of SharePoint’s many great features is the ability to have multiple views of
content, with the flexibility for users to filter and modify the view on an ad hoc,
temporary basis. But not with folders, in a folder view you get just one view of
your content and it is pretty poor, for the reasons above and below. Using
metadata, you can create unlimited number of views by whatever properties you have
setup (i.e. organize documents by date, by customer, by project, etc.).

17. Can’t Sort & Filter


Burying files in folders means you can only benefit from the sorting and filtering
capabilities of document libraries and metadata navigation within the folder you
are in.

18 Inflexible
It’s hard to change the folder structure (though again you can use Windows
Explorer), while changing metadata is easy and can be done as bulk actions.

19. Lost documents


It is so very easy to misplace documents by putting it in the wrong folder and not
knowing where it is. So then you create a duplicate copy, and the mess begins.
Navigation
When you are in a particular sub-folder, there is no easy way to tell which folder
you are in and no easy way to navigate to the parent folder, a sibling folder etc.
since there is no breadcrumb trail or tree view by default.

20. Cost
If all you are doing is recreating the same mess of nested folders you had on file
share within SharePoint all you have done is increase the cost (SharePoint
infrastructure is more expensive than a file server) and you have cunningly avoided
almost all the benefits of SharePoint.

21. Visibility
The only way to know how active a folder is/how many documents it contains is to
open it. It could be empty; it could have ten thousand documents; you just don’t
know. A grouped SharePoint view in SharePoint using metadata shows many docs are in
each group (and lets you carry out counts and other basic arithmetic on column
values, such as Average file size). If there are no items in a group then the group
doesn’t clutter up the screen.

22. Data Integrity


There is little control over the naming of folders, so you can have spelling
errors, non-standard conventions, unhelpful abbreviations etc. Metadata driven
views can be driven by lists and taxonomies to avoid this.

EXCEPTIONS

The big problem is that folders are traditionally used to categorise content,
whereas they were originally designed to group content. Just because we have
learned to use folders inappropriately doesn’t mean we should continue to do so.
However folders have some legitimacy for their original purpose. If you genuinely
need to group files together then you can use a folder in SharePoint; this is
usually because you need to perform a group action on them, such as delete them
all. Similarly folders may be used (despite point 5 above) to assign grouped
security to the content – simply moving a file into the folder gives it some
security; as long as the security rules are very simple to apply and understand. In
both cases you still should avoid folders – use a Document Set instead, since they
are much more powerful, intelligent and intuitive. Even then we strongly advocate
having only a single level of folders and never, ever more than two,
The only other reason for retaining is that you can’t get users to adopt the new,
better way of doing things. At this point you have to use your judgement –
generally staff work for the company and the company can dictate ways of working;
there are rules for not operating machines without guards, even though they can be
somewhat inconvenient for operators (until it saves one losing an arm); the digital
health of your knowledge is as important. However if a team or individual chooses
to stick with folders for their own content then that may be OK; as long as it
doesn’t disadvantage other staff and that they aren’t wasting company resources
(working time, support desk resources, computing time) in the process. A suitable
policy for use of your intranet can address this – shared content, core business
processes, managed information should not allow use of folders in libraries;
personal and team working areas may use folders, but should avoid deeply nested
folders, should also use flat views (where the folder structure is hidden) and must
be actively managed by the team to avoid duplicates and misfiling.

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

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.
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 might also like