Collect Data Workflow Bonus Issue from Jim Bob Howard

Just a quick note to let you know that I just released a new bonus issue for the Understanding SharePoint Journal mailing list. Members of that list know that I will be getting some help in writing the USP Journal this year, and the first author announced is Jim Bob Howard. I’ll quote his introduction from the new bonus issue:

Jim Bob Howard is a husband and father, senior software engineer, and web designer. He is a published writer on numerous topics from homeschooling to frugal living to theology to SharePoint. He has been doing software and web development off and on professionally for 15 years for companies of all sizes.

Jim Bob will be writing a full issue for the USP Journal this fall, and to introduce you to his writing, he has created a bonus issue for the USPJ mailing list. In that 32-page bonus issue, you will learn how to create custom task lists for a collect data workflow in SharePoint Designer.

Oh, and did I mention that the issue is free, as in beer? You get access to the new free content section when you sign up for the mailing list, and in that section you will also find all the other free USPJ content.


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

SharePoint 2010 Solution Sandbox

Note: Keep in mind that any speculation on SharePoint 2010 Features at this point is highly speculative. In theory, Microsoft could change the whole thing into a word processor or Minesweeper II – Day of Destruction without anyone being able to complain; don’t base important decisions on pre-release information.

If you have ever worked with developing code on a shared platform, you have likely faced the problem of multiple solutions deployed to the same farm or application.

In SharePoint 2010, Microsoft has gone out of its way to improve the solution framework. I have already written about the SharePoint 2010 Features Upgrade and Versioning support, but apparently, Microsoft has more aces up their sleeves.

Enter the Solution Sandbox. And quite frankly, that’s about all that’s known at this point, but we can deduce something from the newly released SharePoint 2010 SDK beta.

Here’s what I wrote about this in the SharePoint 2010 Beta series of USP Journal, the first issue of which is now free:

“The solution framework is getting a major overhaul, as mentioned, and a class that hints at a new feature here is the SPUserSolution class. The SPUserSolution class allows SharePoint solutions to be deployed at a specific site collection and run in a sandbox on that site without affecting other site collections.

Even more hints at this come from the SPFeatureReceiverProperties class, now exposing a new property called UserCodeSite. The UserCodeSite property returns the site collection object where the current feature runs, or returns null if the feature is globally available.

Sadly, very little other information is available, but an interesting comment may indicate yet another improvement to the framework. The SolutionId property remarks state that multiple solutions in a library may have the same solution ID, and this indicates different versions of the same solution. “

This is a major change in SharePoint, and hopefully, will improve the development experience by allowing isolation of solutions during testing and development. If this is intended as a production scale feature, it will allow shared hosts to deploy solutions only to specific customers. Clearly this would improve the SharePoint hosting experience, and could even be used to allow customers of shared hosts to deploy their own solutions.

But again, this is highly speculative at this point, so ignore everything I just said.

Note: The first issue of the SharePoint 2010 Beta series is now available free, after the major controversy the last couple of weeks where even Microsoft themselves tried to stop this series from being published. However, to get future issues, you will need to sacrifice $14.95 to the well-being of Understanding SharePoint Journal.


Pin It

SharePoint 2010 List Throttling

This is something new I also discovered in the SharePoint 2010 SDK beta.

You probably know that there is a best practice to avoid lists, or actually views or folders, with more than 2,000 items. Joel Oleson wrote a bit on this in a recent article, describing Managing Lists and Libraries with Thousands or Millions of Items. You’ll also learn some extremely valuable information about how to work with such huge lists.

Now, Microsoft are smart people, they understand that people don’t necessarily follow best practices all the time, especially end users who shouldn’t be expected to know the intricate details of how the SharePoint platform works. End users will happily throw gazillions of items into a list, happy that they finally have a place to store their info, and they shouldn’t be expected to know that this may cause performance problems.

So, for the next version of SharePoint, Microsoft has taken the bull by its horns and implemented list throttling. Basically, this allows the administrators of a SharePoint installation to set hard limits on how big lists, views, and queries should be, before an exception is thrown.

Let me quote what I wrote in the first issue of the SharePoint 2010 Beta series of USP Journal.

[…] there is a new property [of SPList] called IsThrottled that reveals some information about the performance enhancements of SharePoint 2010. In a web application, you can now set a MaxItemsPerThrottledOperation, and if the number of items in a list, as retrieved by the ItemCount property, exceeds the value from the property, the list is throttled.

The throttling works by causing SPList queries to throw an SPQueryThrottledException to avoid performance overload.

However, the SPQuery now includes a new property called RequestThrottleOverride. Basically, this property lets the SPQuery request an override of the throttling, which will allow some users, defined by the farm administrators, to bypass the exception.

So, it seems that it will be a lot easier for administrators to maintain and manage performance in a site with large lists.

By the way, you can read the first issue free at


Pin It