Solve Item-Level Permission Performance Problems in SharePoint

Have you ever had a requirement stating that a document library needs to have item-level permissions for a large number of items? For example, perhaps you need to create a document library to house customer financial statements or invoices, giving the customers permission to access only their own items.

One approach would be to create a separate document library for each customer, and handle permissions at the library level. However, this solution would be a headache to manage. Having thousands of document libraries to handle only a few documents per library is not a reasonable approach. Besides, do you really want to have to create a new document library for each new customer?

Another approach would be to have one document library for each type of document. For this example, you would create a single document library for customer invoices containing separate folders for each customer. You could then handle permissions at the folder level. Seems reasonable, right?

The Problem

If you've ever tried either approach, then you probably know that item-level permissions in SharePoint can cause serious performance issues. That's because when you create a new item in a document library and "break permissions" (stop inheriting permissions) from the parent library, SharePoint automatically copies all the permissions from the parent document library to the item level.

After breaking permissions you can call the BreakRoleInheritance function in the SharePoint API to clear out the copied parent permissions, setting its CopyRoleAssignments flag to false. However, the API does not do a mass delete of the permissions; instead, it iterates through the permission list, deleting them one by one. For example, if you have 5000 folders, it will need to delete 5000 permissions—one by one—in your new item's access control list. That's because each customer needs a "limited access" permission to the top-level library, which tells SharePoint that the user has permission to something at a lower level (i.e., a document or a folder). In the single-library-multiple-folder strategy, each new customer would have "limited access" permission to the top-level library and each new item would automatically copy down those limited access permissions from the library when the item was created. If you do the math, 4000 items * 4000 limited-access permissions per item equals 16 million unnecessary limited access permissions!

I tried using this strategy with a console application that imported documents; it eventually required 20 to 30 minutes for each new customer! After doing some performance testing with this approach, it turned out that the worst-case scenario for uploading 4000 to 5000 documents would have been between 2 and 3 months, which was obviously unacceptable.

So if clearing the parent-level permissions isn't a good approach, suppose you simply set the CopyRoleAssignments flag to true? SharePoint would still break the permission inheritance of your item, but it wouldn't clear out all the unnecessary permissions that already existed. Unfortunately, that doesn't work well either. You might think that it wouldn't matter whether there are extraneous limited-access permissions in each of the folders—but you'd be wrong! Leaving the extraneous permissions can cause serious performance issues when viewing the document library or adding new permissions, because it exponentially increases the number of permissions SharePoint has to iterate through to figure out what access a logged-in user has. My real-world testing showed that it would take over 15 minutes to view the documents!

So it would seem you're between a rock and a hard place. Cleaning up the permissions when creating the folder causes your import to be slow, but if you don't clean up the unnecessary permissions, viewing the documents will be slow. What are you supposed to do?

Luckily, there's a neat little trick that allows you to do both. If you move a folder within a document library to another location in that library, SharePoint moves its permissions along with it. In other words, if you create a new folder in a library with zero permissions, and then move it, you won't have to do any messy cleanup of limited-access permissions.

With that background under your belt, here's the process: