Before deploying our workflow, it would behoove us to make use of the Check Workflow button. Go ahead and click it. If you typed everything correctly, you should get a message box telling you that your workflow contains no errors. If you don’t get this, go back and check that you’ve completed each step correctly.
Now we’re ready to deploy. You might want to pause here for a minute and get yourself a drink and snack before beginning this next part of the process because it’s a doozy and you won’t want to stop in the middle.
All ready now? Good. To deploy our workflow, simply click the Finish button in the Workflow Designer. The SharePoint Designer will validate our workflow, build the initiation form, and deploy the files to the SharePoint site. When it is finished, it closes the Workflow Designer and returns you to SPD.
Man, that deployment was hard work. Go ahead and take another drink now. You’ve earned it.
Drum roll please… Congratulations, you’ve just created your first Office 2007 Workflow.
Testing 1, 2, 3…Testing 1, 2, 3
Before we can really say that we’re done, we need to test our workflow. This will give you the opportunity to see how your workflow looks, too. To get started, fire up a browser and navigate to the site you deployed the workflow to (the same URL you specified when you opened the site in SPD). From here, navigate into the Marketing Plans document library and upload a new document.
Once the document is in place, run your mouse over the document name and select Work- flows from the drop-down menu. Near the top of the next screen, in the Start a New Workflow section, will be a listing of the workflows that are available in this document library. You will likely have two default workflows (Approval and Collect Feedback) plus our custom workflow (Product Marketing Plans), as shown in Figure 4-23.
Go ahead and click our workflow name to get it started. The first screen you’ll see (shown in Figure 4-24) is the initiation form that SPD created for us based on the fields we specified. Fill in some test values for each field and click Start.
Figure 4-23. Our custom workflow is available in the list of workflows to start on our document.
Figure 4-24. SPD automatically created this initiation form for us based on the fields we specified.
Our workflow will start and we will be returned to the view of our document library, as shown in Figure 4-25. You’ll also notice in Figure 4-25 that a new column has been added to this view. The column is named for our workflow—Product Marketing Plans—and contains the current status of our workflow; in this case, it is currently In Progress. This column is added to the default view the first time a new instance of a workflow is added. Any documents or list items that have run or are running this workflow will show their status in this column.
Figure 4-25. The default view of our document library shows the current status of our workflow.
If you recall, the first step of our workflow checked whether the subsidiary was US or UK and then sent an email and assigned a task to the appropriate product manager. If you check the email for the account you set up as the product manager, you will see our email sitting there. A sample of this email is shown in Figure 4-26. Notice that the workflow lookups we added to the body of the email message have been replaced with the appropriate information.
Back in the browser, if you check the task list, you will see a new task created with a name of Review Plan (US) and assigned to the account you set up for the US product manager. Figure 4-27 shows this task as well as the Complete Task button that’s provided to allow us to indicate when the task is finished. Go ahead and click the button now.
Figure 4-26. The email sent by the first step of our workflow has the appropriate information for this instance and this payload.
Figure 4-27. The task created by our workflow
You can click through the tasks and emails that are sent by the other two steps in our work- flow. You’ll notice that each step only executes when the tasks (To-Do items) from the previous step have been marked as complete. In the case of the third step, it only executes when both tasks from step 2 have been marked as complete.
Notice, also, that the status of our workflow back in the document library stays as In Progress until the last task—assigned to the marketing director—is marked as complete.
So there you have it. In just a short amount of time, we’ve built and tested a custom work- flow using nothing but the out-of-the-box capabilities of SharePoint and the SharePoint Designer. Before we close up shop on this functionality, there are a few things you should know:
• There is no way to save your in-progress workflow in SPD. Once you start, you need to deploy it in order to save your work. Don’t ask me why—that’s just the way it is. • As I said before, SPD is great for what it is intended for. However, it is not, repeat not,
going to meet all of your needs. For pretty basic, straightforward workflows attached to a single list or document library, it is a great tool. It does have some pretty significant limitations in this release, though. My recommendation is to familiarize yourself with the tool first on some basic test balloons before you try to tackle something more complex. Make sure that it is the right tool.
• With that said, if it is the right tool, it will save you lots of time.
• There is no way to do escalation, parallel branches, or other more advanced workflow constructs with this tool.
Summary
For the seriously time-pressured among us, here is the abridged version of this chapter. For more information on any of these items, you ought to at least skim the chapter. Thanks.
• In Office 2007, FrontPage has been rebranded as the SharePoint Designer.
• The Workflow Designer in the SharePoint Designer follows a wizard-based process to allow nontechnical users to build workflows.
• Workflows are built as a collection of steps.
• Initiation forms allow you to collect information from an originator of your workflow and use it later in the workflow to do conditional routing, updating lists, and so forth. • The Variables Editor walks you through the process of adding variables to store values
used elsewhere in the workflow.
• Conditions control which steps, or which parts of steps, are processed. • Actions are the meat of the workflow; they’re what the workflow does.
• The SharePoint Designer ships with certain out-of-the-box actions readily available to cover many situations you are likely to encounter.
• The Workflow Designer works directly with a single list on a single site. It is not intended for creating workflows that are to be deployed to multiple lists or sites. (This is not to say that you can’t make that happen; it’s just not what the tool does well.)
• Workflow lookups allow you to retrieve information from other lists in your site or from variables set as part of your workflow.
Here’s some food for thought:
• The SharePoint Designer is good but it still requires a client install and a fairly knowl- edgeable power user. It would be interesting to build a purely browser-based interface for building very basic workflows. There has also been some discussion in the commu- nity about building a workflow designer right into the core Office applications via a task pane. I’ll post some thoughts on my web site and point you to some of the discussions elsewhere in the community. I’d love to hear your thoughts on this.
• The Workflow Designer is built for simple, single-path workflows. For example, there is no way to automatically escalate a workflow to another user if one user doesn’t complete their assigned task within a certain period of time. Yes, there are two delay-type actions, but they are going to block your whole workflow and prevent any additional steps from processing, even if the user does complete their task in the time allotted. You could probably cobble something together but it wouldn’t be pretty. It would be an interesting discussion on how to make it work easily. Visit me at http://kcdholdings.com if you have ideas and would like to discuss them.