There are additional considerations when using custom workflows created in SharePoint Designer 2007. For example, some companies don’t like users to apply changes directly through SharePoint Designer 2007 to the production environment and may block the ability to make changes and/or additions to a site using SharePoint Designer 2007.
A major consideration in creating workflows in SharePoint Designer 2007 is that, by default, those workflows are tied to a specific list within a SharePoint site: They are not portable, cannot be copied and/or moved to another document library within a site, cannot be deployed across an entire farm, and do not get saved as part of a list or document library template. In addition, workflows created in SharePoint Designer 2007 cannot be associated with a content type, which removes the ability to centrally tie a custom workflow to content across site collections.
Note
While a workflow created in SharePoint Designer 2007 cannot be associated with a content type, a content type can be leveraged to meet certain conditions. For example, "If Content Type equals <nameofContentType>" then perform the following action.
Figure 10-5 shows an example of a workflow step within SharePoint Designer 2007 that includes two sets of conditions, each including a Compare field in the If and Else If conditional branches where each compare is based on a specific content type within the associated document library.
As mentioned, a major design consideration when you deploy SharePoint Designer 2007 workflows is that those workflows are specific to a single list (or document library) within a SharePoint site. Unlike out-of-the-box workflows, it’s not easy to save a custom workflow created in SharePoint Designer 2007 as part of a list template. Several files are created as part of a SharePoint Designer 2007 workflow, including the main .xoml file, which will launch in the Workflow Designer; the .xoml.rules file, which instructs the main .xoml of any specific rules within the workflow; and the .xoml.wfconfig.xml file, which includes the site and list, or library, ID where the workflow will run and also whether the workflow will start manually or run automatically as a new list item is added. In addition, if you include initiation or custom forms as part of your workflow, those forms will be saved along with the other workflow files as .aspx files. Each workflow, along with its files, is stored in a workflow folder within the site where the workflow was created and is accessible from within SharePoint Designer 2007.
Many folks have asked if it’s possible to move a custom workflow created in SharePoint Designer 2007 to another document library or site. If you try to simply copy the workflow folder from one site to another (or copy a document library to another document library), the workflow may in part work but will generate errors. Trying to modify the .xoml files is tedious and will not guarantee successful results when you attempt to port a custom workflow between sites. Any forms associated with the workflow won’t work if they are moved to another document library or site. In this case, and where additional workflow functionality beyond the out-of-the-box workflows is required, the obvious choice would be to create a custom workflow in Visual Studio 2005, which would then give you the flexibility to deploy that workflow throughout an entire site collection.
But there’s light at the end of the tunnel. Let’s assume you’ve created your custom workflow in SharePoint Designer 2007, but you must now apply that same workflow to multiple lists throughout your SharePoint deployment. One solution is to create a new custom workflow in Visual Studio 2005. But what if you’ve already done most of the workflow design in SharePoint Designer 2007? Rather than duplicate work unnecessarily, one option is to port the SharePoint Designer 2007 workflow to a workflow template in Visual Studio. Many have asked whether it is possible to take a workflow created in SharePoint Designer 2007 and re-use it, or part of it, in Visual Studio. Until recently, this was not considered possible. However, at the SharePoint Conference 2008 held in Seattle, Washington, Todd Bleeker of Mindsharp demonstrated this very process. He will eventually detail steps to do this in a series of blog posts at http://mindsharpblogs.com.
Note
A best practice for porting SharePoint Designer 2007 workflows to Visual Studio 2005 is to ensure that the stakeholder defines the SharePoint Designer 2007 workflow before mass deployment via Features/Visual Studio 2005 to avoid unnecessary re-cording by developers. For example, ensure that any .aspx forms and custom activities are defined and documented before the handover to developers.
Finally, workflows created in SharePoint Designer 2007 cannot be edited via the browser or directly from the document library or list to which they are deployed. They must be edited in SharePoint Designer 2007. Attempting to edit a SharePoint Designer 2007 workflow in the browser will result in the dialog box shown in Figure 10-6.
Figure 10-6. An error dialog box appears when you attempt to edit a SharePoint Designer 2007 workflow via the browser.
There are approximately 23 out-of-the-box workflow actions included in SharePoint Designer 2007, including custom calculation actions to logging information to a history list back in the associated SharePoint site, as well as other custom actions, such as updating list items (based on a certain condition being met). However, you are not limited to using the out-of-the-box workflow activities and can create your own custom workflow activities to suit your business processes. A number of custom workflow activities have already been created within the community and added to the CodePlex site, http://www.codeplex.com/SPDActivities. Numerous blog posts that include instructions on how to create your own custom workflow activities are also available.
More Info
A set of open-source custom workflow activities that can be installed and used in SharePoint Designer 2007 when workflows are created has been added to the CodePlex site. But remember, these are open-source activities, so use them at your own discretion. Todd Baginski, a SharePoint Server 2007 MVP, has also documented steps for creating custom workflow activities along with how to deploy custom activities to SharePoint Designer 2007. These steps are available at http://www.sharepointblogs.com/tbaginski/archive/2007/03.aspx.
Where you’ve branched out and chosen to create and deploy custom workflows throughout your SharePoint environment, you must consider some issues involving configuration, such as when you redeploy modified workflow assemblies.
Workflows start off in w3wp.exe, which loads the workflow assembly from the Global Assembly Cache (GAC). When the workflow hits a delay, it puts an event in the queue for OWSTimer.exe to pick up at the scheduled time. When the time comes, OWSTimer.exe loads the workflow assembly from the GAC.
However, if you modify and redeploy the workflow assembly into the GAC and do an iisreset, starting a new workflow will make w3wp.exe pick up the new workflow, while OWSTimer.exe still has the old workflow cached. Because of this mismatch, the workflow may crash and appear to hang indefinitely. Thus, when you reset the timer, it flushes the cache and, on next load, it picks up the same assembly as w3wp.exe.
Note
The preceding two paragraphs are attributed to Eilene Hao, Program Manager, SharePoint Workflow, Microsoft, whose original post and associated comments can be found at http://blogs.msdn.com/sharepoint/archive/2008/01/04/issues-with-the-delay-activity-in-sharepoint-workflows-we-need-your-help.aspx.