Overview

If you’ve worked with SharePoint designer for long, there’s a good chance that you’re hit a wall of one kind or another. For example, there is no good answer to the problem of securing tasks. Workflows often assign tasks, typically by:

• Using the “Assign Task” action.
• Creating an item directly in a task list using the “Create Item” action.
• Using the “Collect data from a user” action.

Each approach has its ups and downs, but they share one common flaw: SharePoint Designer does not provide any mechanism for securing those tasks. This damages our ability to create robust business solutions.

Scenario

Consider a typical business problem, MRO purchasing. MRO refers to “maintenance, repair and operations,” and generally refers to purchases employees make in order to do their job. These would include mundane things like paperclips up to more costly purchases such as laptop computers. The archetypical MRO process works like this:

• An employee fills out a requisition form requesting the item.
• The employee’s manager approves it.
• Depending on cost or other standards, another manager may need to approve it.
• Upon final approval, the purchasing department orders the product.

SharePoint Designer workflow can bring us fairly close to an automated solution for that process. We can use a custom list or InfoPath form to capture the requisition. We can use SharePoint Designer to implement the workflow solution that, among other things, assigns a task to the manager seeking approval. However, we run into a wall with security. We obviously don’t want a person who enters a requisition to be able to approve the requisition. However, we can’t control security settings from the workflow itself, so it’s not possible for us to assign a task with the correct permission level.

To properly solve the security problem, we really have no practical option except to do some coding. Commonly, developers will write an event receiver on the task and change the permission level. An event receiver is a .NET program created using visual studio that, when properly configured, runs in response to an “event” such as creating or editing a task. End Users, naturally, don’t create event receivers.

SharePoint Designer leaves us hanging in other ways too. We can’t do much in the way of string manipulation (e.g. find a substring of a main string), assign tasks and then send our own custom emails in response, get current user information from the profile (such as display name or the user’s department) … the list goes on. All of this information is fairly easy to obtain for a developer, but it may as well be on Mars for most End Users. What to do?

Enter Custom Actions

The solution to this problem comes in two parts: Custom Actions and a partnership.

Like an event receiver, a custom action is a program, normally written using Visual Studio written in C# or Visual Basic.NET. Developers follow some rules, copy some files in the right places and SharePoint Designer users can use it this action to build workflow solutions. Properly implemented and installed, it looks similar to the following:

The screen shot shows a category of workflow actions named “Dispatcher.”

These custom actions look and feel just like any other of the standard actions we get out of the box, such as “Log to History List” or “Send an Email.”

Custom actions are great, yet … how do we get them in the first place? They have the same drawbacks as an event receiver — .NET code, visual studio, non-trivial to create, deploy and configure… This begs the question, “why mention these at all?” Like event receivers, they may as well be on Mars as far as them being useful to the typical End User. End Users don’t create custom actions.

This leads to the second part of the solution – a partnership. End Users should seek to partner up with developers to create custom actions.

I think that in general, End Users should try and partner with developers anyway. Successful businesses are always forming partnerships with other businesses, people partner with each other and collaborate on projects – End Users and developers shouldn’t be any different.

Custom SharePoint Designer workflow actions, however, make for an even better arrangement. It lies in the same category as “give a man a fish and he eats for a day but teach a man how to fish and he eats for a lifetime.” In this case, we re-reword it: “Create an event receiver for an End User and he solves one business problem today; create a custom SharePoint designer action and that End User solves business problems for life (and will be out of the developer’s hair for months and months!)” Once a developer creates and tests the custom action, End Users can leverage the work everywhere.

An event receiver is almost always limited in scope to a specific business requirement. It’s certainly possible to create an event receiver solution that solves a wide variety of business problems. However, line for line, effort for effort, a custom action for SharePoint Designer will normally pack more punch.

When Partnerships Are Scarce

In many companies, it’s not easy to partner up with developers. There may not be any developers to start. The developers may not have the technical know-how to create custom actions. The IT department may have erected walls between themselves and the End Users, or other cultural barriers exist. There isn’t any easy answer to that problem. Communication is key and the sooner you start building up a relationship the better. However, End Users do have other options.

While you’re building up a strong relationship with your IT counterparts, check out some of these online resources.

• “Useful SharePoint Designer Activites”: Available at http://www.codeplex.com/SPDActivities, this CodePlex project includes a nice collection of new SharePoint Designer workflow actions. They include a set of actions around security, email and other useful features.
• Workflow Essentials: At this time, a beta product which I assume will be available commercially in the near future. It looks to be a comprehensive suite of new custom actions and conditions. Check it out here: http://moss.sharepointsolutions.com/SharePoint-Add-ons/Products/Pages/WorkflowEssentials.aspx
• My own small effort: Yours truly put together a small set of custom actions up on CodePlex here: http://www.codeplex.com/spdwfextensions/Release/ProjectReleases.aspx?ReleaseId=8487

Summary

SharePoint Designer workflows are wonderful things. However, often times, they are frustratingly incomplete. They take us to within 10 feet of the finish line in the big race and then leave us stranded.

The good news for End Users is, paradoxically, the bad news: custom actions bring us that last 10 feet to the finish line. Yet, End Users simply don’t have the technical know-how to create custom actions. To solve this problem, leverage your existing developer partnerships on a personal and cultural/institutional level.

In the mean time, look to the SharePoint community as a whole for help. It’s there with open arms.

Paul Galvin, Microsoft MVP – SharePoint
Web site: Paul Galvin’s SharePoint Space

Paul is a Solutions Architect currently working most closely with Microsoft Office SharePoint Server 2007. He was recently awarded Microsoft MVP – SharePoint status for his work with the SharePoint community.