Blogging about SharePoint

I just got a copy of "Microsoft Office SharePoint Server 2007 Best Practices" by "Ben Curry and Bill English, with the Microsoft SharePoint Teams".  Last night (7/30/2008) I perused the table of contents and read all of Chapter 10, "Business Processes and Workflows".  The book is, of course, available from Amazon here: MOSS 2007 Best Practices

The table of contents is quite appealing as the book covers a number of topics that I am interested in other than workflow - including branding and information architecture.

However, I've only read chapter 10, so here is my assessment of it, section by section:

P263-268 - Review of the workflow capabilities, with a little bit of discussion of requirements analysis.  This feels like little more than product documentation.  In the boxed text on p269 is the first real advice on workflow: a risk of a serial approval process is that it can get hung up indefinitely if one of the approvers is unresponsive (e.g. on vacation or leaves the company).  Here's another good point: parallel approvers should have equal authority and respect within the approval process. In other words, it doesn't usually make sense to give Johnny the intern and Bob the CEO equal approving authority while requiring both of them to be involved in the process.

Another interesting tidbit from the boxed text on p269 is that a serial approval workflow probably maxes out at 1000 participants, though I suspect few processes would actually involve more than 10 participants, be they people or groups.

Additional Best practices on page 269:

1. Minimize serialization, using additional workflows instead.  Hmm, I'll have to think about that.  I don't see how additional workflows help, but rather I can see having workflow logic that moves the process forward in some way (e.g. escalate a task) if the current task is not completed in a defined amount of time.
2. The originator [the person that causes the workflow to kick off] (and often others in the process) need to stay informed of the progress of the process.  Sometimes alerts in email are sufficient to do this.  Other times, the workflow itself should generate emails to the appropriate parties. 
   • An example of this in my current project is that a user uses a Line of Business (LOB) web app to submit a request.  The LOB web app drops a list item in a MOSS list, and an approver then gets an alert in email that a new request has arrived and requires attention.  When the approver reviews the request and changes the status of it, the workflow then puts together an email to the requestor's department's e-mail distribution list, and calls a web service to update the LOB web app.

The rest of page 269 is on the Workflow History list, which continues through the top of page 272.  Although neither a good nor bad practice, but rather just a fact, the workflow history list does not show up in the normal places in the UI - e.g. Quick Launch nor View All Site Content pages.  You primarily see it through the workflow status page, although you can guess the URL to get to the default view of that list.

On page 270 there are some best practice statements about when to use a new history list for each workflow vs when to combine them.  One of the things to take into account is if users will sync the task list with Outlook.

• In my recent experience, I have created two workflows around two business processes that are part of an existing LOB web app.  The web app runs outside of MOSS on a separate web server, but tosses list items into a MOSS site via calls to MOSS's web services.  In this situation, we have a site collection for use by the web app, with a site for each business process.  In this situation, each workflow has its own site and so it has its own history list too.  We haven't encouraged the users to sync the tasks with Outlook. 
  • In fact, I have an issue where if the user edits the custom task by arriving at the task's application page directly from the Edit Task link in outlook, the redirect statement that I use when they click the Task Completed button on the application page causes an error.  But that's not related to syncing with outlook, just related to task notifications in Outlook.

Page 270-271. If you move a document to another library, its workflow history will not move with it.

Page 271, boxed text, talks about how workflow history isn't appropriate for auditing. This is one of Robert Bogue's blog posts.  Good stuff, but since I read Rob's blog, it feels a bit like filler here.

Middle of page 272-top of page 273 is on Publishing workflows and to me reads more as product documentation than best practice guidance.

Middle of Page 273-top of 275.  A discussion of how various workflow options can be used to meet various business requirements.  Not "Best Practices" advice, but good solution design information.  For example, you can control use of custom workflows at the web app level and (via permissions) at the site level.  Workflows are a very empowering feature, but a real world reason to turn them off would be that you haven't had a chance to train users on them yet.

Sidebar, page 275.  Now here's a nugget I like.  This is a blog post I hadn't seen before, and will be looking into more closely due to my interest in site provisioning solutions (I am giving a presentation on site provisioning solutions, as well as one on getting started with MOSS administration, and one on information architecture at SharePoint Connections in Vegas in November).

Page 276-279.  Discussion of SharePoint Designer workflows.  Frankly, I'm not that excited about SharePoint Designer workflows.  This may be a personal bias, as most of the work I do is for IT departments and therefore it's highly likely that my customer will have a code promotion process (i.e. a migration of custom functionality from a development environment to a staging environment to a production environment.)  Because of this deployment requirement, I've used SharePoint Designer to prototype workflows, but Visual Studio to build them.  And I have not bought into the idea of migrating the workflow definitions from SharePoint Designer to Visual Studio.  I tried that with a fairly complex workflow that I built in SharePoint Designer, and what I got was a huge pile of workflow activities and a complex rule file that was an unintelligible and unmaintainable mess.  All the activities had meaningless auto-generated names and I have come to dislike rule files because you can't put breakpoints in them like you can with code methods.  I found it much more practical to rebuild the workflow in Visual Studio rather than migrate it.  The resulting activity graph was much easier to understand, maintain, and debug.

All that aside, there are a few useful tidbits in here: SPD workflow emails have to have subject lines; SPD workflows can't be associated with content types.  The "best practice" in the first box on page 279 is more about good project management practices than about SharePoint.  I'm fortunate to have worked with some very good project managers and engagement managers recently. 

Top of page 280 has a description of how a workflow can be executed by more than one process - first w3wp and then OWStimer, but it's content that is quoted from http://blogs.msdn.com/sharepoint/archive/2008/01/04/issues-with-the-delay-activity-in-sharepoint-workflows-we-need-your-help.aspx

Bottom of 280 to bottom of 282 is again primarily product documentation.  Very bottom of 282 to top of 283 is a section on naming conventions for workflow lists, which is useful.

283 to top of 285 is mostly product documentation again, but 285 starts a section on security concerns that I did find useful.  You may want to give the workflow history list different permissions from the site permissions, so that you can better control who can read or write history entries.  You can also give the document library that has the workflow associations different permissions than the parent site to control who can start a workflow.

And finally, on page 286 a chapter summary followed by a list of four links on page 287. 

--Michael