So, what what content roll-up web part to choose? Well, typically (for SharePoint) it depends.
Bamboo’s List Roll-up Web Part is the most feature rich, but a bit tricky – certainly it’s a bit too complex if you’re wanting to allow users to set up their own roll-up. The use of CAML is also a big no-no for allowing basic users to set up their own. It’s a shame; it really is let down by this complexity, although it’s still simpler than using SharePoint Designer.
Using the Dataview Web Part directly has the same problem as Bamboo’s List Roll-up – complexity. It also requires SharePoint Designer. It’s harder to generate the Data View Web Part, but to be honest (given that you can do the same things as Bamboo’s List Roll-up web part) I suspect that most organisations would be fairly willing to live with that.
For me, it’s main problem is that it doesn’t pick up new lists automatically; you have to modify the data view web part to add the new lists. For that reason, I think you can only use this approach when you have a fixed set of lists to aggregate over.
The Content Query Web Part is pretty good, and there is a reason that it’s so often discussed in SharePoint Solutions. The web part itself is fairly straight forward to use – but using custom metadata in the display is a bit too complicated. Again, I think this solution is out of the range of the ability of typical users. I don’t like the lack of pagination options, either.
Lightning Conductor is the only one of the web parts that struck me as being simple enough that a non-technical person would be able to set up and use for content roll-up. It had many of the more complex features that we’ve seen (e.g. using XSL for formatting the results), but you didn’t have to use them, and the user interface exposes things that seem missing from the CQWP – like the ability to select the fields you want in the display! I’ve got to say, this is my favourite of the solutions I looked at.
So which one should you use? Well, as I said, it depends. The main factors involved seem to be:
- Are you wanting to aggregate across site collections?
- Are the source lists fixed, or will they be changing?
- Will the roll up be configured by technical or non-technical staff?
I guess you weigh those up and take your choice.
Edit: One questions I was asked was if it’d be difficult to write your own. Well, there’s no reason why you couldn’t; with the SPSiteDataQuery it wouldn’t even be hard. Programming around the configuration would take longer, and as we’ve seen, this can make a big difference to the usability of your solution. What I would observe is that both the 3rd party solutions were pretty cheap; it’d be diffult to write your own for as small a cost.
Edit 2: A good post on when to use the CQWP vs the Lightning Conductor Web Part from Lightning tools…
| Introduction | Content Query Web Part | Data View Web Part |
| Lightning Conductor Web Part | Bamboo’s List Roll-Up Web Part | Conclusions |
Andy Burns' Blog 
[…] So, on to the conclusions… […]
Nice analysis of Rollup options. But I wonder about one aspect of the Data View Web Part (DVWP), where you say “given that you can do the same things as Bamboo’s List Roll-up web part”.
Suppose you need to roll up several lists in a site. The lists have some columns in common, but they also each have some unique columns. I believe Bamboo List Roll-up handles that.
But can a data source (for a DVWP) be constructed in SharePoint Designer to merge the common columns of several lists that don’t have exactly the same columns?
The documentation about this says “all the data sources [lists to be merged] must contain exactly the same fields”, but possibly that means a VIEW of the lists must be exactly the same. However, there is no designation of view mentioned when selecting the lists for the data source.
Any suggestions to clarify your statement and resolve my issue about DVWP and Bamboo would be appreciated
Hi John,
“But can a data source (for a DVWP) be constructed in SharePoint Designer to merge the common columns of several lists that don’t have exactly the same columns?”
Yes, it can! I’ll blog about it shortly, but the quick description is:
– Open SharePoint Designer, then ‘Manage Data Sources’.
– In your Data Source Library pane, expand ‘Linked Sources’ and Create a New Linked Data Source.
– Select your sources, and how you want to merge them (I’ve only tried merging into one list, rather than joining).
– Then use this data source for your Data View Web Part.
Presto! And as for…
“The documentation about this says “all the data sources [lists to be merged] must contain exactly the same fields””, well, I have empircal evidence that that is wrong, at least some of the time. I have two content types, both children of Document but with different columns, and they merge and display just fine.
I’ll try and post about it soon, but I’m going home now!
Andy – thanks for the suggestions, which certainly seem encouraging. I’ll try it out and look for your future post too.
Also, I’ll try to figure out what the documentation is actually saying about merging. Sometimes, I think, descriptions under-rate WSS capabilities while implying MOSS would always be better.
Lightning Conductor webpart is amazing slow. It’s literally the same as the Content Query Web Part.
I didn’t find it particuarly slow, and although it looks similar, it is:
1) Easier to use (e.g. displaying extra columns)
2) Has sorting on column headers
3) Works across site collection boundaries (which is frequently painful).
Yes, the Content Query Web Part and Lightning Conductor do basically the same thing, but the latter does more. I might not use it if I had simple requirements or access to an SP developer, but for general users, Lightning Conductor is more useful.
Phew… this post just saved me hours of googling tonight in order to work out exactly what to go forward with as regards roll ups!
Have stumbled upon all three thinking they did something different, started playing with them but then started wondering myself as to the difference…. great summerisation of all 3.
THANKS 🙂
🙂 Thanks for saying thanks! Made my morning!