Item-Level security boundaries are defined in the Software boundaries document at 1000 items.

In the Advanced List Settings you can specify Item-level Permissions to "Create items and edit items that were created by the user"

Now, if I use these settings on a list where users will be submitting forms for an approval workflow, where the requirements are that a user can only see forms submitted by him (leaving the requirements for approvers permissions out of the equation for now), does this mean I can only have 1000 forms in this list before I start to kill SQL?


3 Answers 3


Item level Security is a sweet posison from the performance site of view. Have a look at this Article for Details

  • Thanks. That explains the performance hit at 2000 items :-( May 15, 2012 at 7:13
  • 1
    Just some snippets from the linked article for reference: "When you load up a huge list with lots of item level permissions, a single operation gets every single GUID associated with the ACL for that item and passes that back to the data access layer of SharePoint. (...) it will pass in all of the ACL Guids back in as one long string, all concatenated together." "Passing 640k of data about the place, for a SQL Query to do some substring math and converting to Guids will soon bring your database server to its knees. This is one request and it takes 2000ms to work." May 17, 2012 at 6:42

In the Advanced List Settings you can specify Item-level Permissions to "Create items and edit items that were created by the user"

Those doesn't break permission inheritance and thus doesn't count in the 50'000 unique item-level permissions.

Also please read this question: Sharepoint 2010 Item level Permission to a Document Library is Our approach right? It countains some good resources that explains about item level permissions and performance, particulary this resource: Best practices for using fine-grained permissions (SharePoint Products and Technologies)

  • Thanks. This will be a good fallback option. The 50.000 is actually a hard limit, but a more detailed read of the document shows that the actual limit is still between 1.000 to 2.000 May 15, 2012 at 7:12
  • @JorgeCarvalho please see edited answers to see some additional resources that helps understand performance implications and best practices with fine-grained permissions May 15, 2012 at 8:55
  • Thanks for the links Janis. In the other question thread there seems to be a discussion around the 50.000 items, when in reality, your SQL won't hold more than a couple of thousands. The second link is the same I have in the question comments. Thanks for putting some time into thi anyway. Cheers May 17, 2012 at 6:44

Can you not move the documents once it reaches a certain level? Do they have to stay in the same document library or list?

If not I would use Information Management Policy settings and have them moved to an archive once they are not needed.



  • Yes, we'll have to think of something along those lines, some form of archiving that will carry the workflow information with the List item. It's just that the solution became considerably more complex due to this limitation, and I was hoping to get some workaround. At the moment the solution seems to be to fallback to the list setting "View only my items", modify permissions for approvers while WF is active, and restore inheritance at the end of the WF. This will reduce the number of unique permissions to the number of active WFs. A bit more analysis still required to validate this approach May 15, 2012 at 7:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.