Design Patterns for Collaborative Apps – Recap of my session at the SharePoint Conference 2008

I'm writing this from my hotel room in Seattle, where I've just attended the SharePoint Conference 2008. The conference was great, and it was an excellent opportunity to meet up with SharePoint friends old and new.

I did a session called "Design Patterns for Collaborative Applications", and at the session I promised a recap with all the links from the talk, so here it is!

The idea for the talk came from working with many customers over the last few years, and noticing patterns in the solutions I worked on with them. The talk focuses specifically on collaborative applications ... that is, extending SharePoint's collaboration features to provide more integration with business processes. I showed four "patterns", each of which I've seen in multiple customers. In this post, I'll summarize each of the patterns and provide the links to the resources mentioned in the talk.

1. Business Entity Workspace

The idea here is to combine dashboards with team sites, so users can access all the information about a business entity, including both structured (LOB and external) and unstructured (documents, events, contacts etc.) information in a single user interface. Some real-world uses include:

  • The MTC where I work has a site for each engagement that also surfaces our CRM system and other tools, so everything is in one place

  • A property management company wants all the information about a property in one place, including maps and financial reports as well as leases, contracts, etc.

  • An company wants all the information about its customers in one place, including contacts, documents and financial data

  • Another company wants its product information in one place, including sales performance, documentation, etc.

I showed two ways to do this: one had a pair of web pages (a selector and a detail page), with the selector passing an entity ID to the detail page much as the Business Data Catalog profile page gets its entity ID from a query string parameter. The other had a hierarchy of sites, with a child site for each entity. The core of the solution is using Filter web part connections to select the right data to show; an advantage is that most of the built-in SharePoint web parts can consume a filter connection.

I demonstrated a new web part I wrote called the "BDC Multifilter" which, rather than just providing a single filter with the entity's ID, can provide up to four additional filters with various attributes of a BDC entity. You can even combine multiple attributes, to make a street address out of address, city, state, country etc. for passing to a mapping web part. The BDC Multifilter, along with a Virtual Earth web part (that consumes an address as a gilter) and a search web part (that consumes a query as a filter) are all available for download now at I also acknowledged that I saved many hours building the demo by using the BDC Metaman tool, available at, which I can recommend after the experience.

2. User Self-Service

This is a very common scenario: a user fills in a form, and a workflow runs to coordinate a business process which ultimately updates a line-of-business system. Some examples include:

  • An expense reporting application

  • Legal services, such as requesting a legal review or contract

  • Requesting a new job requisition to hire an employee

  • Taking on a new customer or engagement that requires approval and updating a CRM system

The tricky part is making it secure while providing flexibility to the business. I showed how to create custom activities in SharePoint designer - that provides the flexibility. A great and usable sample is available on Codeplex at - the sample provides a number of new activities that work within SharePoint, but of course you can write your own to do something else. The process for writing a custom activity for SharePoint Designer is located at

The security issue is that someone could write their own workflow to skip the business process and approvals, and just update the LOB system. The .ACTIONS file that defines the custom workflow activties is global, so even if you lock down security on the site that you expect people to use to, say, file an expense report, someone with admin rights to some other site might be able to invoke the "reimburse employee" action without the fuss and muss of having any real expenses. In addition, it's important to lock down the form ... imagine that someone alters the form to show one total to the approving manager, and hides a much larger total in the XML that controls the reimbursement.

The fix for this is to:

  • Dedicate a web application to the self-service scenario

  • Deploy your custom action code to the /bin directory of that web applciation ONLY

  • Lock down any and all sites/site collections that run in that web application so only trusted users can control the form and workflow

Another approach is to create a custom workflow in Visual Studio that includes the business process and forms along with the LOB access. This doesn't allow business users to change the workflow, however ... you decide if that's desirable or not. Yet another is to use BizTalk to manage the LOB update, and to enforce the business rules in the BizTalk orchestration. And, before someone points out the omission, there is are a variety of 3rd party workflow solutions out there that could be used.

3. Team Knowledge Base

The idea here is to provide team feedback about shared knowledge, be it a collection of documents or, as I showed in the demonstration, a wiki site. This comes up a lot in services organizations (Microsoft Consulting Services has a custom SharePoint solution called ICE that does this), and often for use by customer service reps who have to quickly answer questions on the phone. I demonstrated another internal tool that was developed by a local partner, Burntsand, that provides ratings and comments on a SharePoint Wiki. Since this isn't publicly available, I pointed attendees at another Codeplex gem, the Knowledge Base Web Part, available at

Part of the discussion was about where to store the ratings. Unless you want users to be able to "stuff the ballot box" by rating an item repeatedly, you need to keep track of individual users' ratings so they can change their rating but still only get one "vote." In the application I showed, this is stored in a set of SharePoint lists (one per Wiki page). When a user rates a page, the average is recalculated and stored right in the page for speedy access. This works well to a point, but with more than a couple thousand users (or rated objects) it's likely to slow down; in that case I'd recommend storing the individual ratings in a cusotm SQL Server database.

4. Team Tracking Workspace

The scenario here is that a team of people are working on a coordinated release of documents. Typical business scenarios include:

  • Proposal development

  • Ad campaign development

  • Books, magazines, and other publications

  • Business case development - for a new product or service

If the deliverable was code, Team Foundation Server would be a logical tool. If the deliverable is documents, SharePoint workspaces are a natural fit ... if equipped with a tracking mechanism.

The solution I showed stores document status in a SQL Server database, but I'm working on getting it to stay in SharePoint for easier re-use. Item status can be shown across all projects (each project in a child site), sections of a project (each section a document library), folders, and documents. The status is based on the approval and versioning information in the document, but in some cases more status values are needed, for a multi-level approval scenario or other multi-stage business process. SharePoint event handlers run whenever a document is added, changed or removed, and update the database accordingly.

I'm working to package this up in a general purpose way, but it may take a while since this is a "nights and weekends" type activity and I'm not sure when I'll get to it. In the meantime, if you really need it, you could develop something similar or, if you engage Microsoft Consulting Services and send the consultant to me, I can share the code through the consultant. It's a combination of it not being packaged very well, and some legal aspects which would be covered by the MCS work order.

Another, complimentary solution I showed was a very cool "Document Splitter" that breaks a Word document down into multiple section documents, and then stitches them back together, much as a slide library does for PowerPoint presentations. This is Chapter 8 in my friend Ed Hild's APress book,  Pro SharePoint Solution Development: Combining .NET, SharePoint and Office 2007. I highly recommend this book; each chapter presents a very useful Office Business Application (OBA) solution that incorporates the Office 2007 client and Office SharePoint Server 2007, and with the book comes the code I showed. (I also recommend Ed's blog, I was pleased that the two solutions worked so well together, with just a bit of tweaking to get Ed's custom actions (split and merge menu items) to work with my "tracked document" content type it all came together in about half an hour's work. The result was an ability to have a team concurrently developing various sections of a single document, and tracking their progress throughout.

I hope the session was valuable, and offer my thanks to those who attended!

 This posting is provided "AS IS" with no warranties, and confers no rights. Thank you for reading it!

Comments (1)

  1. Nick says:

    Hi Bob — your session was great. I had approached the Business Entity problem by making a selector web part that internally filtered, constructed, and sent an object (with most of the required information) to a set of web parts that were able to consume/display it. Just one page, but not very flexible, nor could it easily take advantage of sharepoints capabilities.

    A question — can you suggest a strategy for managing permissions that differ in different parts of the heirarchy?

Skip to main content