Random Thoughts on SharePoint-based Workflow
I'm doing a session for the New England Code Camp later this month (Code Camp 7: Deer in Headlights!
- http://www.thedevcommunity.org/CodeCamps/) on workflow development with Visual Studio. See the abstract at the end of this blog.
I've been working with MOSS workflow for a little bit now and have accumulated some (mostly) random thoughts...
- There is no such thing as a simple workflow. I am reminded of this almost daily. Every business rule has an exception and it's hard to build "forgiveness" in a workflow engine. Allot the proper development time... AND documentation.
- Never design workflow based on the exceptions. It's easy to get caught up in the many variation of routing that ultimately constitute less than 20% of the use cases. Avoid them! Put them somewhere else. Business users can give you all kinds of workflow rules but will walk away quickly when the process seems confusing or too complicated to manage. Build to the majority (use cases)... especially for new (to MOSS) users.
- Build a workflow portfolio. Workflow is too hard to envision (especially when you factor in the newness of MOSS itself). Users need to see something but it takes too long to build an effective prototype. You run the risk of a throw-away design. Stockpile workflow demos. Showcase them. Let business users align themselves with a concept then build a prototype from it. This will also help with effort estimation.
- Educate the users (early). An effective workflow can have major impact on business processes... when expectations are properly set. Building a workflow that manages the movement of content is now natively available (in MOSS with SharePoint Designer and custom VS solutions). Building a system that provides line-of-sight into all assets being affected/managed by that workflow is not a natural by product (i.e. "It would be nice to see a report of all our assets, grouped by the various stages in our workflow, to give us clear insight into potential bottlenecks" -- nice indeed!). This is another reason why workflows should be as simple as possible... it's too easy to lose sight of all your assets. It is just as important to explain to users what the new workflow will NOT do as it is to explain what it will do well.
My upcoming session...
Building SharePoint 2007-based Workflow Solutions with Visual Studio 2005
The new workflow capabilities inside Microsoft Office SharePoint Server (MOSS) 2007 make automating business processes easier than ever. As developers, however, we are quickly faced with the challenge of extending the native workflow options available in SharePoint Designer. This session will walk attendees through the custom workflow development process within Visual Studio 2005. It will include code samples and steps for exposing the new workflow back into SharePoint Designer.