Document and Folder Level Permissions

One of the most common issues people run into, especially those migrating from SharePoint Portal Server 2001, is the absence of folder level security. I have talked to many customers about this issue, and while I can’t offer any solutions (It is security and this is not something to be messed with or “worked around”), I can talk around the way I think about it.

Permissions can only be set at the “Document Library” level within Windows SharePoint Services, in some ways this is actually no worse than what was available in SPS2001 (except that there is no “deny” facility on documents, but that was not all that useful anyway). Why? Well, you will hear me say this a lot (you wait, a few months and my blog will be number one for these terms), software is developed with a number of constraints, predominantly time, resources and money, unfortunately this was just one of the things that our SharePoint team was not able to accommodate.

Now, while I agree that it does appear to be a decrease in functionality, I would offer the following pieces of advice:

Try to avoid the use of “Folders”, I have found that there are very few genuine reasons for creating them, and that customer requirements can often be better met by the creation of custom metadata and custom views. There are a number of benefits to this approach including:

a.       It is difficult to move documents between folders in WSS, at least via the web only interface (easier with Explorer, but what about versions and metadata?), but very simple to change the value of a custom property.

b.      By assigning metadata to a document you are improving its ability to be discovered via search. The metadata value becomes part of the documents description.

To illustrate some of these benefits lets take a scenario. You have a set of files relating to a number of projects you are currently working on, Project A, B and C.

There are a number of approaches to organising this content but I will take the two most obvious ones to illustrate my point:   

1.       Create three “Folders” to store the documents, users then navigate to the document library they are interested in.

2.      Create a custom property, a choice field, with each of the projects listed. Create three views, each filtering on this property so that you can select a view to display only the documents for each project. Modify the default view so that it displays the documents “Grouped By” the custom property.

The benefits of approach (2) are as follows:

a.       To move a document between projects you simply modify the value of the metadata.

b.      Search will index the “Project” property on each document, making it easier to find documents relating to a specific project.

c.       Easier navigation for users. There is no “Windows Explorer” style folder tree view in WSS (at least via the web interface) so navigating down multiple levels of folders requires many clicks.

This approach has been successful with a number customers I have worked with, in one case reducing a complex 5-level deep document hierarchy to just 7 individual document libraries, four of which have folders only one level deep. This has made it much simpler for users while enriching the content itself by the smarter application of metadata.

Finally, to be clear, I’m not saying never use folders, sometimes they make sense, mostly because it is a paradigm users are familiar with, but I am saying spend time working out if there is a better way to do it given the capabilities of SharePoint.

Comments (21)

  1. Steven Collier says:

    In your scenario I would still think that folders would work better than the metadata. Your views, groups etc will work just fine through IE but if a user is opening a file from within word they will just see one long list of files, the folders would still have shown.

    I think there is also something around security, you need much higher rights in order to change a choice list compared to creating a folder.

    Document Level security is available in Office 2003 through rights managment, and this is a much better solution than item level security on a storage location.

  2. Agreed, it’s horses for courses, absolutely sometimes folders make more sense, there are some good reasons.

    The thing about organising documents is that metadata is KING! Carefully and accurately describing your documents is critical to making them findable.

    On document level security, rights management is a great option. But again horses for courses, some security requirements are still better met via security built into the storage technology.

  3. We are just getting going with SP2003.

    Whats this metadata thing ? Are you talking about metadata on a document library (list) ?

    if so, how do you set that metadata ?

  4. Yup, I’m talking about the metadata on a document library. These are basically the column that you define. You set it by using the link to the left of the document library called "Modify Settings and Columns"…Hope that helps.

  5. George says:

    Describe your understanding on the difference between folder level security and network share security, and how they interact with each other. Which is least restrictive, which is most restrictive?

  6. Nick Longinow says:

    Can one set document library metadata using the shipping ms web services ? or any other way programmatically ?

  7. Daniel McPherson says:

    Hey Nick,

    I dont believe you can set document library metadata (that is the "Columns" via an out of box web service. However this functionality is provided via the SPS OM, and you easily create a custom web service that did this for you. Take a look at the following sample:

  8. Ron says:

    I’m curious about security in Portal level document libraries. I’m working with a client who has created Areas and SubAreas for their various departments.

    Within a SubArea, they want to set up different document libraries and specify which users can see which document libraries.

    With DocLibs in WSS, there is an option to manage security. With DocLibs in Portal, that option doesn’t exist.

    Is there a way to security these document libraries on the Portal level? For now, we’re hiding them using audiences, but I’m not sure that’s the best solution…


  9. Daniel McPherson says:

    Unfortunately there is no way to achieve this with the current version of SharePoint.

    The decision was made to restrict the granularity of permission on the Portal to the Area level only. There were both architectural and functional reasons for this.

    Audience targeting will work if just "hiding" the documents is enough, note though that this is not security, any users with access to that area will be able to access those documents. For example by performing a search.

    Hope that helps,


  10. Ron says:

    Thanks for the quick response. That is what I thought was the case. The decision to organize the company’s departments into Portal Areas was made before I joined the project…

    Hopefully, we can make this work without moving all the departments into WSS Sites….



  11. KANJI says:

    how we can do it folder level security by way of programming

  12. KANJI says:

    how we can do it folder level security by way of programming

  13. Daniel McPherson says:

    My initial response is that with enough programming anything is possible…but…

    I believe any programming effort to achieve this would not only be very large, but involve significant risk from a security perspective and significant ongoing maintenance costs.

  14. Anders Munck says:

    I ran into the same issue, but we went in other directions because I also thought using "folders" was a bit old-fashioned and I wanted people to think in terms of the new Sharepoint Services functions.

    At Carlsberg we’re therefore looking into specifying read-rights on ListViews instead, which will give us a lot more flexibility in distributing content.

    The other (and more difficult) thing we’re trying is to set read/write rights on specific metadata so that certain users can change content status without changing content, but that has proved virtually impossible without taking the whole WSS system apart.

    Anybody else working on alternate ways of handling permissions?

  15. Daniel McPherson says:

    What you are doing sounds interesting Anders, just so long as you are very careful.

    Modifying standard security mechanisms in our products is not for the feint hearted. In fact I would go so far as to say it would be nearly impossible to customise SharePoint to such a point that content would become TRULY secure beyond what the product provides out of box.

    That said, "Security" by obscurity might be achievable. While that isn’t really security, it may meet your requirements.

  16. Point2Share says:

    Interesting discussions (Mart Muller) here and (Edward Ferron) here about SharePoint Document Libraries,…

  17. WWs Blog says:

    Daniel McPherson has a really good article about Document Libraries in SharePoint, the article brings…

  18. Point2Share says:

    Well, it’s been 2 years of Point2Share!

    I’m a little late with the Anniversary, but it seems I started…