26 October 2015

SharePoint Capacity Planning with Nintex (Part 1)

Using Nintex Workflow to automatically manage thousands of Nintex Forms or other SharePoint List Items

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, and 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.
Of course, SharePoint supports 30,000,000 items in a list or library!
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? Ideally one that is reasonably generic so that it could be reused across multiple lists if required?

The Solution

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.

Number of Subfolder Levels
Subfolder Levels
Expected items created per day
Up to 12
Year and Month
Up to 150
Year, Month and Day
Up to 5000

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:

Subfolder structure for automated filing and capacity management

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 as 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

Implementation Considerations

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 article.

There is always a trade-off in software development, and in this case, the selection to use a UDA increase reusability but 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.

24 May 2015

Slide Deck from Office 365 Satuday Perth #o365per

Massive thanks to Haylee for organising another very successful Office 365 Saturday event in Perth, and thanks to the sponsors, presenters and attendees for contributing to the day!

As promised, here's the slide deck from my presentation: "The evolving Office 365 landscape - Build and Ignite".

I hope that everyone picked up something useful from the presentation and from the day.

02 May 2015

SharePoint Explorer updated with the latest Office 365 CSOM APIs

For those that may have missed it, Microsoft recently released a significant update to the CSOM capabilities of Office 365.

So that makes it a great time to update the SharePoint Explorer tool that I have blogged about previously (here and here).

The updated download is available here. Please read through the previous blog posts to understand the tool and its usage.


19 February 2015

Visual Studio intellisense for NWF$ - jQuery inside Nintex Forms

Those who have written custom JavaScript to act within Nintex Forms are probably familiar with the NWF$ construct which is the name that Nintex has given to the jQuery object - which by convention is usually called just $.

This allows us to harness the power of jQuery but necessitates using a different naming convention that Visual Studio intellisense just doesn't understand. So, here's a quick tip on how you can get everything working nicely in your IDE.

Firstly, work out the version of jQuery that is in use (I can see from tracing my browser session that Nintex Forms 365 is currently using version 1.10.2, from https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.10.2.min.js).

In your Visual Studio project, open up the Package Manager Console (you can find it from the "View" menu under "Other Windows"), and type in the following command (note the version number is used to make sure intellisense knows exactly which commands should be available):
Install-Package jQuery-vsdoc -Version 1.10.2
This will bring in the appropriate files for jQuery and intellisense, but intellisense will only work against the $ or jQuery names, not against the NWF$ name as used by Nintex.

To allow intellisense to understand the NWF$ name, we need to amke a small modification to one of the files added by the Package Installation process. In the Solution Explorer, find the file whose name ends with vsdoc.js - in my case, this is jquery-1.10.2-vsdoc.js. Open up this file and scroll right to the bottom, where you'll see this fragment:
jQuery.fn = jQuery.prototype;
jQuery.fn.init.prototype = jQuery.fn;
window.jQuery = window.$ = jQuery;
Now add the following line:
NWF$ = jQuery;
so that the end of the file now looks like this:
jQuery.fn = jQuery.prototype;
jQuery.fn.init.prototype = jQuery.fn;
window.jQuery = window.$ = jQuery;
NWF$ = jQuery;
Save the file, and that's it!

Now, when you start using NWF$, Visual Studio will understand what you're doing and will help suggest jQuery functions for you:

Visual Studio intellisense against the NWF$ object