SharePoint Solutions: 3 Challenges

Reading Time: 4 minutes

I design and build solutions in SharePoint. I have varying levels of proficiency among the tools available to me and I’ve noticed a few common challenges across solutions I build, regardless of the tool chosen. This post gives an example of a solution I recently built to highlight some typical challenges and why estimating can be difficult.

The details of the solution are explained here to frame the challenges I discuss later on.

Solution: This was built in SharePoint 2013 to allow end-users to identify a BI report link displayed in search results as a personal “favourite”. This list of favourites could be surfaced elsewhere on the site for subsequent quick access. Behind the scenes each favourite would be stored as an item in a SharePoint list.

A prototype was quickly built and shown to the end users. They liked what they saw and wanted it implemented as soon as possible. Sound familiar? I needed to “harden” the solution for real-world use. This is usually the point when challenges start to surface.

Here are 3 I typically encounter…

Task1Challenge #1 – Build for Growth

Experience has taught me to build any solution with content volume and threshold limits top of mind right from the beginning. The solution needs to handle whatever you’re throwing at it with ample room to spare.

Building for growth in SharePoint can be handled in many different ways: folders, content organizer, information management policies, etc. For this solution, we needed to ensure we remained within the list view threshold limit by using folders.

If you’re reading this post, I’m assuming you’re already familiar with the default list view threshold of 5000 items. If not, the link is HERE. I suspected there would be more than 5000 items in this list over time so I needed to ensure we wouldn’t run into this boundary. Enter challenge #1.

To stay within the limit and to improve the efficiency of data access, the items would need to be inserted into folders (each of which could contain up to 5000 items) and all list views would need to be filtered on indexed columns.

My intent was to design an automated folder structure. Since the folders would only be used for performance reasons, their names didn’t have to make sense for navigation. Requirements were:

  1. The number of items in each folder should be spread across all folders and must remain under the 5000 item limit.
  2. There should be a reasonable number of folders.
  3. Ideally, they should be created ahead of time.

I decided to use the last 2 digits of the employee number (00 through 99). These are issued serially to employees and meet all 3 requirements above. Based on the number of employees, this would allow each employee to create up to 50 favourites (10 times more than average) and allows plenty of room for growth. PowerShell was used to automatically create these folders in advance.

There’s a significant amount of thought (and time) that can go into determining something as simple as a folder naming standard, and for good reason.  Time spent coming up with a good structure could prevent performance/threshold issues down the road.

Task2Challenge #2 – Pick the Right Tool

If you’ve spent any time building solutions in SharePoint, a skill you’ve no doubt honed is the ability to adjust your original design if (when) challenges arise. This solution was no exception.

I created a custom search item display template to include an “Add to my Favourites” link on each search result.  When clicked, a REST API call was made in the background to insert the item into a SharePoint list. While this worked in the prototype environment, it now needed to be inserted in a folder due to challenge #1 above.

Well, how hard could that be? Ha!!

After many hours of struggle (did you build this into your time estimate?) and with some very smart people in the community assisting, it was discovered that the current state of the REST API was unable to insert an item directly into a SharePoint list folder. Enter challenge #2.

I had a decision to make; do I stick with the first solution and find a way to make that work OR do I abandon it altogether and use a different tool capable of inserting the item directly into the folder in the first place? If so, what is that tool?  Decisions like these face SharePoint practitioners every day. You need to weigh the pros and cons (sometimes quickly), make a judgement call, and forge ahead.

For this particular problem, I decided to stick with the first solution and add a workflow to move the item into a folder.

The point here is to emphasize how important it is to know the tools of the trade and what each tool’s capabilities are so you can choose the right tool in the first place.  If you don’t, you risk spending a lot of time reworking solutions.

Was this a perfect solution? No, but it’s reasonably good, meets the end users’ needs, it’s supportable and was completed in the allotted time. That’s success in my opinion.

Task3Challenge #3 – Avoid Optimistic Estimates

It would have been tempting to be lulled into a sense of confidence after the prototype was developed and assume the bulk of the work was already done.  DO NOT DO THIS.

I can’t tell you how many times I’ve been burned by this, but it’s a lot.  Time and again, I’ve mistakenly given an overly-optimistic estimate only to find out there are key pieces of the solution not even considered in the prototype. Enter challenge #3.

The prototype is just the beginning.

Take your time and consider everything required to build the complete end-to-end solution in SharePoint. There are things you’ll know to estimate in advance (Eg. information architecture, threshold limits, permissions, governance, information management policies, testing, documentation, training). The tricky part is estimating for those things you’re blissfully unaware of at the beginning. If you’re lucky, you won’t have many of these things, but if you’re unsure, build a contingency into the estimate. You’ll thank yourself later.

I’ve learned this lesson the hard way over years of SharePoint experience. For this solution. I gave an estimate of 2 days to complete the work after the prototype. I used every bit of that time to complete it.



Most solutions I build in SharePoint have these 3 challenges. I’d love to know if you’ve run into the same ones when building yours.

Thanks for reading.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.