SPTechCon: Everything You Need to Know to Plan SharePoint Workflows, with Mike Fitzmaurice

SPTechCon: Everything You Need to Know to Plan SharePoint Workflows, with Mike Fitzmaurice

by | Oct 25, 2010 | The Bamboo Team Blog

Bamboo Workflow Conductor

Mike Fitzmaurice presenting on "Everything You Need to Know to Plan SharePoint Workflows" at SPTechCon BostonAt SPTechCon Boston early Friday afternoon, Mike Fitzmaurice presented his session, Everything You Need to Know to Plan SharePoint Workflows.  Mike began with a brief history of SharePoint workflows, including an explanation of how SharePoint workflow works, concluding his presentation with a series of “lessons learned” during his years working with SharePoint workflows.  Mike defined the goal of his session as to provide advice on “how to do workflows well, and how to avoid making mistakes.”

Mike referred to Windows Workflow Foundation as having been created “to make life easy for those of you who want to write workflow applications,” explaining that its common scheduler, persistence API, tracking and batching operations all contribute to the cause.  Mike explained that SharePoint is a host for Windows workflow, and provides additional services for workflows.  Discussing Visual Studio, Mike suggested that a Visual Studio template could be thought of as “a map, or guide to the workflow actions, or activities, [that] tell the workflow what to do.” 

Discussing the difference between declarative and code-based workflows, Mike said that with declarative workflows, “You’re deciding what you want a code assembly to do,” and that declarative workflows are published to containers (e.g., lists, libraries, etc.), and “versioned as if they were documents.  Code-based workflows, on the other hand, are packaged as features and are deployed via .wsp packages.

Mike offered some advice as to when a SharePoint workflow is, or is not, a good fit.  Included in the “good fit” category were: managing how people work (e.g., document approval); automating SharePoint behavior (e.g., self-service site creation); and manipulating other applications or data sources (e.g., resource scheduling).  Under the heading of when SharePoint workflow is not ideal, Mike discussed: transaction-oriented processes; application-to-application service activities; aggressive data transformations; and any instance where SharePoint isn’t really involved and is merely a “supporting cast member, or bit player.”

Mike then moved on to the lessons learned section, “the meat of the presentation,” which included the following advice:

  • “To avoid bottlenecks, you need to distribute the work.” This is necessary because “Demand will always exceed supply, because who’s got an infinite supply of developers?” Mike suggests delegating simpler workflows to users to help alleviate such bottlenecks, and said that “SharePoint Designer is fine for this,” cautioning that “some oversight and training is necessary, and policies may be.”
  • “It’s not all about forms.” Because, as Mike pointed out, “The form is not the workflow; the form is the user interface,” and “The UI isn’t nearly as important as what the process is,” so, “As much as possible, let the workflow do the work.” Furthermore, Mike recommends “one form per task, not one form per workflow.”
  • “State machines are not esoteric.” Recommending that if you “Break the workflow up into stages, you’ll have a much easier time,” Mike suggests that you “think workflow with multiple phases.”
  • “Expect to get it wrong the first time.” Because “Your decision and execution model needs to factor in that it is going to need to be modified.” Mike submits that “The process will probably need to change before it can be truly automated,” and strongly recommends that you “Automate the process before you automate the individual steps.”
  • “Revising a running workflow” is never advisable, and doing so should be avoided if at all possible.
  • “Reusability isn’t automatic.” To increase the likelihood of developing a reusable workflow, Mike recommends using lookups (e.g., employing a lookup to determine Manager) rather than hard-coded resolutions (e.g., Manager = John Smith) wherever possible.
  • “Measure so you can manage.” Mike explained that SharePoint workflow logs information in lists, and that as a result, the data is available to you for review and refinement of workflows.

 

Bamboo Nation’s complete coverage of SPTechCon Boston 2010:

Get a Demo
Contact Us
Newsletter Signup