SharePoint 2010 Workflow for Multiple Items (Architecture)
I had the question today of whether SharePoint 2010 supports workflow on multiple items, since Groove's workflow apparently supported multiple items and that model disappeared when Groove Workspaces were amalgamated into SharePoint Sites and SharePoint Workspace (the client utility). It's a great question, the short answer is that yes, it's possible. You could brute-force it in 2007 and that strategy should still carry over to 2010, and 3 new features (that I can think of) support multi-item scenarios more easily in 2010.
First, the brute-force method in 2007: While each workflow is associated with a single list item, there is also a property bag available on the workflow where you could store references to additional items, or a reference to a second workflow running in parallel, depending on how the processes for each document need to interact. The caveat is that this strategy is both complex and code-intensive; in addition to the code necessary for the two workflows to work in synch and respond to events on the other, you should consider whether your scenario requires a housecleaning process to clean up orphaned processes or items, or any similar indirect "exception handling."
There are three new constructs in SharePoint 2010 I can think of that make it easier to build workflow for multiple documents: document sets, site workflow and list relationships. Document sets are a new way to associate documents with each other; for example a set of project deliverables (e.g. budget, requirements, project plan and design). Document Sets are a new content type (inheriting from folder), and any workflow associated with a Document Set will apply to all documents within each set. In this scenario a constraint is that the documents remain "near" each other since the sets do inherit from the folder type. Also note that Document Sets are a SharePoint Server (SPS) 2010 feature; they are unavailable in SharePoint Foundation (SPF).
Site workflow is similar to the List workflow available in 2007, but the Workflow History and Task lists are scoped to the site collection rather than an individual site, and the workflow itself doesn’t have properties to associate with or to "watch" specific items. The advantage is the wider scope that the workflow works at, and the trade-off is having to write your own monitoring for the lists and libraries. A site workflow can span libraries or sites within a collection, though you would use the workflow property bag to list associated items or documents, and would likely use event receivers to trigger workflow events from the libraries where those associated items are stored.
Then you have List Relationships. You can now create a foreign-key relationship between columns in two lists. It should then be simple for a workflow on any given item to get a reference to a related item and “do something” with it.
I suspect that any choice between these will be driven by how the workflow is to be initiated. With List Relationships the workflow is still associated with a single item and the relationships drive the reach into additional items. With Document Sets you first identify the items as a set and then launch the workflow on the set. With Site Workflows you would build a custom mechanism to launch the workflow and identify the items it should apply to. If there’s another scenario, or you've encountered issues with any of these strategies, I’d be interested in your story.