SharePoint Capacity Planning
One of the great myths of SharePoint surrounds the List View Threshold. The common story goes like this: someone creates a list or library with the default configuration, then suddenly it starts getting some serious use. Once it hits 5,001 items, people start seeing strange behaviour. People then conclude that SharePoint can’t handle any more than 5,000 items, and negative impressions of SharePoint are the result.
Effective use of large lists generally requires just a little bit of capacity planning around your views and indexes. A simple approach is to use folders and subfolders to ensure that there is a maximum of 5,000 child nodes (items and subfolders) at any given level. The best way to ensure such a folder structure is maintained is to completely automate it and remove any need for human intervention. Nintex Workflow to the rescue!
The Business Problem
A client came to me recently and asked about implementation strategies for a Nintex Form that was going to receive several hundred submissions every day! Clearly some capacity planning would be required, otherwise the list would become unmanageable very quickly.
So how can we construct a simple but clear Information Architecture, and ideally one that is reasonably generic so that it could be reused across multiple lists if required?
The approach that I suggested was to build a subfolder structure that separates items based on a date. The date can be separated into year, month and day components, and the approach can use one, two or three levels of subfolders, depending on the expected capacity. Items would be stored at the leaf nodes in the structure.
The following table gives a sense of the capacities that would require second and/or third levels to be used, ensuring that we never exceed the 5,000 list view threshold.
So for my client and their hundreds of forms every day, we would need to use all three levels.
Here’s a diagram of how this folder structure would be constructed, and also a naming convention which aligns chronological ordering with alphanumeric ordering:
For each item to be filed into this structure, we need to nominate a specific date for the item. This date value could be the date of item creation, or in a Nintex Workflow context, it could be the date when the Workflow meets a milestone point such as process completion.
Managing Item URLs
Nintex Forms are managed within SharePoint as List Items rather than Documents, and List Items have a very neat property whereby you can move them around the folder structure within a library, without changing their URLs! So we can move items into their subfolder structure at any time within their lifecycle, without impacting on end users or creating dead hyperlinks. Note that if you try this with documents, then you’ll see that the URL of each document will change to reflect its position within the folder structure, and this will lead to broken hyperlinks and frustrated end users!
This approach will work with any List Items, including Nintex Forms, but is not as neat for Documents because of URL changes.
This solution concept is very generic; it only requires the list items to be associated with a date. It is not coupled to the schema of a specific list or a Nintex Form schema, so we can implement the process within a User Defined Action (UDA). The UDA can then be quickly and reliably dragged and dropped into any Workflow across the SharePoint system, gaining huge reuse and management benefits. If you’re not familiar with UDAs, check out this Nintex Community page.
There is always a trade-off in software development, and in this case, the selection to use a UDA increase reusability but in turn introduces some build complexity because list item context is not available in the Nintex Workflow designer.
Stay tuned for part 2 where we build the UDA which automatically files list items into the described subfolder structure, building out folders as required.
Posted by: Martin Harris, Solution Specialist, Portals & Productivity Solutions | 10 November 2015
Rate this post: