SPTechCon SF: Robert Bogue Demonstrates ‘How Workflow Works… and How it Breaks’

Now that I've already posted the most sensational aspect of Robert Bogue's How Workflow Works… and How it Breaks session, it's time to circle back and blog the rest of his information-packed session. 

Robert began the session, naturally enough, with the question "What's a workflow?"  In concert with input from session attendees, he defined the term as being a process that is long-running ("in human time"), "serializable" ("it doesn't have to be running constantly, you can store it"), and the flip-side of that aspect, resumable ("get it out of memory and resume") process.

Moving on to what we can do with workflows in SharePoint, Robert said that seeking approvals and collecting feedback are "really all you'll ever use" out-of-the-box.  Declarative workflows, however, are available with SharePoint Designer, and are customizable.  Robert pointed out that out-of-the-box workflows can also be opened and customized in SharePoint Designer 2010.  Coded workflows, on the other hand, require Visual Studio 2010, with which "you can do anything, but with that great power comes great expense."  Regarding Visual Studio specifically, Robert recommends that you "create an activity that you can use in SharePoint Designer so that most of your workflows can be built in Designer."  As for choosing which approach to use to meet your workflow needs, Robert's key recommendation is to always use the least expensive option possible to achieve your goal. 

Touching on the role of Visio, Robert explained that you can draw the basic foundation for your workflow in Visio, but cautioned that "It's not a workflow tool in and of itself … you have to use Visio with SharePoint Designer."

Discussing workflow templates, associations, and instances, Robert mentioned that workflows are, of necessity, bound to a list, library, or content type, and that each instance may behave differently because different data is bound to it.  Explaining that an association can be started based on an item in a list, Robert said that "You can only have one active instance of an association on an item at a time."

On the topic of workflow history, Robert said that it's "Really easy to write to the history list," but stated in no uncertain terms that "Workflow history is not an audit trail … it's a hidden list to which everyone has access … [and] it's designed to help you understand where your workflow is."  As further evidence of why workflow history can't be used as an audit trail, he said that by default, 60 days after a workflow has completed, the workflow auto-cleanup job will delete much of the history related to the workflow.

Robert defined the SharePoint Designer workflow types as: list (connected to a specific list, not portable), reusable (connected to a content type and portable where the content type exists), and site. How reusable are they?  A reusable workflow can be used within the same site, but not in subsites, peer sites, or sibling sites.  You have to tag a workflow as Globally Reusable in SharePoint Designer to make it available throughout a site collection. 

"SharePoint Designer doesn't support looping or iteration," Robert said, because "They are specifically blocked in the runtime."  There is, however, one exception which proves the rule, as Robert explained: Since approvals are a task, and can loop internally.

Regarding the sandbox environment in SharePoint 2010, Robert pointed out that declarative (i.e., SharePoint Designer) workflows can be deployed to the sandbox, whereas coded (i.e., Visual Studio) workflows cannot.

SharePoint Designer 2010 workflows can be packaged as a WSP file, and Visual Studio can import WSPs, but as for whether you should bring a SharePoint Designer workflow into Visual Studio, Robert said, "I'd have to say no." 

On the topic of sequential, state machines, and flow charts, Robert's recommendation is to "Use a sequence and not a state machine in Visual Studio [because] they're dumping state machines and flow charts … there's not a transition plan."

Touching on the subject of business process management (BPM), Robert said that "Business processes tend to work on skills [whereas] SharePoint is working from the model of assigned tasks [to users] … the models are fundamentally different."  Robert also cautioned that users be aware that "Another issue is that SharePoint throttles its workflows… if it determines the server is too busy, it throws the workflow into the queue to run later."

Robert then began his demo, drawing an example workflow in Visio to requisition a new server process.  After creating the basic steps for the workflow and drawing the connections, Robert clicked the Check Diagram button, which generated an error: "Parallel activities that are also sequential are not allowed."  The problem here, as Robert explained is that "Even though it's a valid diagram, Visio doesn't know how to tell SharePoint Designer how to do it," and gives you a not terribly helpful error message in the process.  To get around the issue, it's necessary to remove the line/sequence that was running in parallel.  Once the offending line(s) have been removed, the diagram will pass muster on the next check.

From there, Robert proceeded to SharePoint Designer for a short demo of how to construct and publish the workflow, then went into SharePoint, starting the instantiation and looking at the resulting workflow information.  At this point, while in SharePoint, Robert added logs to a couple of areas to demonstrate that new items can be added to the workflow within SharePoint.  Finally, returning to Visio, Robert showed that, regarding those items that were newly added in SharePoint, "The point here is that my new activities (log to history) got added to the diagram 'automagically.'"

Read our complete coverage of SPTechCon San Francisco 2011: