Mark Arend : Workflow

Workflow Tips (Part II - Collect Feedback)

markarend — Wed, 19 Jul 2006 20:55:00 GMT

Collecting feedback from a user as part of a workflow is easily configurable out of the box, but may not be quite intuitive at first pass. Here’s a simple explanation of how to get values back from the user as part of a workflow step, then use those values in your workflow for making further decisions.

Add “Collect Data from a User” Activity

Add an activity to your workflow to Collect Data from a User. You will configure three values for this activity: Data, User and TaskID.

Configuring the Data is a fairly straightforward wizard. One twist is that the Description you enter on the first screen of the wizard is what appears on the submission page of the form that collects the data, so put any explicit instructions here, not just a general description.

Then on the second screen of the wizard for Data, enter the name and type of field you would like to collect.

Configuring the User is easy: use the variable you created in Part I of this tip that contains the identity of the workflow participant.

Finally, the Task ID is the key to the task that the user edited, so that you’ll be able to get at it to collect the data the user submitted. So just enter a name that is meaningful to you for this, such as EditedTaskID.

Add Another Activity

At this point, the data that the user submitted is available to you, but it may not be clear how to get at it in order to use it in another activity. We’ll use a Set Workflow Variable activity as an example, and it’s also a best practice because the workflow now makes it clear where data is coming from and it can be reused more easily.

Add a Set Workflow Variable activity to your workflow and create a new variable name to store your value in. Then click the value placeholder to open a wizard, and enter the following values.

Source: the task list the workflow is attached to. If more than one task list shows up, choose the one that contains the custom field you configured in the second step. When you choose this list, the wizard will expand to present more choices.
Field: choose the custom field you configured in the second step.
Field: choose the ID field of the task list.
Value: choose the task ID variable you created in the second step.

This says “Retrieve the Custom Data field from the Tasks list for the entry whose ID equals the ID of the task the user edited.”

At this point, you have retrieved data from the user for this step of the workflow and can use it to make further workflow decisions.

Workflow Tips (Part I - Configurable Approvers)

markarend — Wed, 19 Jul 2006 19:18:00 GMT

Using SharePoint Designer (SPD), it’s possible to create a workflow that can look up a user’s identity from a SharePoint list in order to send email to the user and collect feedback from the user. This technique can be used to make a workflow more flexible, and also to cover the scenario where a workflow participant changes jobs or leaves the company. In this case, a different user can be configured as the workflow participant without having to modify the workflow itself.

As an added benefit, this technique also extends SharePoint’s link fixup behavior to workflows so libraries can be moved without breaking workflow links.

Build a Configuration List

First, create a custom list to store information about workflow participants. The Site Info list in the next figure keeps track of a Content Editor, a Content Approver and the URL of the site. We will retrieve this information using the Site Name, which matches entries in this list (but does not have to match information in the site itself).

For the user columns, pick the User or Group type (of course), then change the value displayed to Name, because the default is Name (with presence) and this doesn’t work.

Now we can build the workflow. Fill in the first screen of the wizard with a title, list and initiation of your choice.

Create a “Set Workflow Variable” Activity

It’s best to begin by retrieving the value(s) you want from the list into workflow variables. This is especially true if you will use them more than once, but even if you just use the value one time, it’s a good practice to put it in a variable for easier maintenance and extensibility of the workflow.

Create a new “Set variable to value” activity, and choose a name for your variable. Then, for the value, click the f(x) button and fill in the wizard as follows.

Source: Choose the configuration list
Field: Choose the appropriate column from the configuration list
Source: Choose the column holding the key to your configuration data. If you took the default when building the list, this will be “Title”
Value: Enter a string that matches the key for the configuration data you want.

This says “Retrieve the Content Editor field from the Site Info list for the entry whose Site Name equals Consulting.” You can ignore the warning about only returning the first item. But take this as a reminder that it only makes sense to use unique keys in your configuration list.

That’s all there is to it! Another step is shown to provide a meaningful example.

Create a “Send an Email” Activity

The next step is to send an email to the Content Editor, with a link to open their task library to approve or reject the content. The To: field in the email is set by a workflow lookup to the ContentEditor variable that was just created.

In the body, we are using a lookup to a new variable we created like the other lookup; this one is for SiteUrl so we don’t have to hardcode that into the workflow.

An important benefit of this is that if the site is moved to another location in the SharePoint hierarchy, the Site Info list will have its links fixed up, and the workflow will continue to work without modification!

This example will continue in another posting to discuss getting feedback from the ContentEditor user after they have completed their edit and wish to kick the workflow to the next step.

Developing custom workflows using Visual Studio 2005 - Getting started

markarend — Thu, 13 Jul 2006 02:28:00 GMT

The beta 2 SDKs both have lots of information including walkthroughs on this subject. Download the SDK installers from:

WSS v3 Beta 2 SDK: http://www.microsoft.com/downloads/details.aspx?familyid=6D94E307-67D9-41AC-B2D6-0074D6286FA9&displaylang=en
MOSS 2007 Beta 2 SDK: http://www.microsoft.com/downloads/details.aspx?FamilyId=05E0DD12-8394-402B-8936-A07FE8AFAFFD&displaylang=en

To develop WF in VS 2005, you really need to be running VS on the same machine as MOSS. Bummer, but there it is. Build a dev server with MOSS and VS.

Here are bits you must install on your development MOSS server if you wish to create workflow assemblies using Visual Studio 2005:

Visual Studio 2005 Extensions for WWF - http://www.microsoft.com/downloads/details.aspx?FamilyId=63A80A4B-BD27-4124-A2A5-61786ADB626E&displaylang=en
ECM Starter Kit for the SharePoint workflow templates - http://www.microsoft.com/downloads/details.aspx?FamilyID=38ca6b32-44be-4489-8526-f09c57cd13a5&displaylang=en

Then, install the SDKs on your MOSS 2007 server to integrate the help files with VS 2005. You will also get the CHM files extracted during installation so you can just open them instead if you prefer.

The walkthroughs call for InfoPath development, and it is most convenient to have InfoPath 2007 client installed on the MOSS server for this, but not required… you could develop the InfoPath portions of the walkthrough on a different box; bit of a pain.

Finally, it may be convenient to link to the Office Online beta information site (http://officebeta.iponet.net/en-us/sharepointserver/FX100492001033.aspx). If you haven't installed any Office 2007 apps, you can install the viewer control to see this site:

Office Online Beta Control - http://download.microsoft.com/download/4/7/7/477d549d-c265-43b4-a8b4-9eb576cba00c/AuthInstall.msi)