In my last post, I discussed some nice workflow visualization features that will be part of the Office 2010 suite. In this post, I’ll review some of the improvements you can expect to see in upcoming releases of SharePoint Designer (SPD) 2010 and SharePoint 2010. There’s quite a lot to talk about here and this is by no means a comprehensive review. The larger point is that Microsoft is adding a tremendous amount of new functionality for “codeless” workflow in 2010. And I believe this is going to add a lot of value for those looking to automate more complex business processes with both on- and off-premise implementations of SharePoint. So here goes…..,
New Workflow Types
Workflows written in SharePoint Designer 2007 can be associated with one and only one SharePoint list. They can’t be exported to a different SharePoint environment and they can’t be used in different lists or sites within a single environment. Happily, the story is different in 2010. There are now three types of workflows available:
- List Workflows – Your traditional SPD workflow. Its associated to a single list within SharePoint.
- Reusable Workflow – Associated to any list or content type that derives a common base content type.
- Site Workflow – Attached to a site and is initiated using the “Site Actions” menu.
So far, I haven’t seen any mechanism to export these workflows so they can be packaged and deployed to a separate environment. I’ll be keeping an eye on that.
Impersonation
Workflows written using SharePoint Designer 2007 execute under the context of the user who initiated it. This presents some challenges for approval processes that involve item content approval in SharePoint. Basically, the workflow can’t do this unless the initiator has Approve rights. This, of course, defeats the entire purpose of the approval process. Microsoft is now adding an impersonation container that removes this constraint, by running all tasks within the container using the context of the workflow author. This greatly simplifies the approval process and helps ensure approval integrity within SharePoint.
Better Error Checking
In SPD 2010, if you have an error in your workflow, you’ll know at design time. And you’ll even know where specifically it is. Yay!
More Flexible Control Flow
Conditions can now be nested within conditions. There’s now a lot more flexibility with the control logic.
New Conditions
Speaking of Conditions, Microsoft is adding (and removing) the available conditions in SPD. Currently there are six new ones (bold green) and four removed. Of particular interest is the ability to check item permissions.
New Actions
At the time of this posting, there are about 18 new out-of-the box workflow actions available through SPD. You’ll notice new abilities to manipulate strings (totally absent in SPD 2007), actions for permission manipulation, record declaration (sweet), setting a custom workflow status, and a totally overhauled approval process that supports both individual items and document sets.
Yes, some of these custom actions already available up on Codeplex and these can be used in MOSS 2007 today. But this list gives you an idea of how far Microsoft is looking to expand the capabilities of SPD workflow in 2010.
Significantly Improved Tools for Approval Processes
Many workflows written in SharePoint Designer involve automatically kicking off an approval process for items. Today, writing something like this with any degree or real-life complexity (like getting multiple approvals for things) can be pretty cumbersome. In SPD 2010, a much richer and more flexible approval mechanism is available. It starts by creating an entire, separate approval process workflow for a given item. This is done with a single Action.
Users can be assigned approval tasks in a serial or parallel manner. In addition, multiple “assignment stages” can be configured. In the following screenshot, you can see how its no longer necessary to manually create multiple approval task items when multiple parties need to be involved. That’s huge. You’ll also see how easy it is to set task due dates and limits between serial approvals.
As I mentioned before, approval is really a self-contained processes. In other words, its its own, associated workflow instance. As such, it can be completely customized (or not). SPD 2010 provides a handy page to do this with.
You’ll notice in the above screenshot that Reassignment and Change Requests are supported out-of-the box. In addition, custom task outcomes can easily be extended.
Speaking of tasks, the look-and-feel and other functionality is much improved. No longer do users need to click Edit to actually review and approve stuff. Users see what they need in a single click. The form includes approve, reject, change request, and re-assignment right there….front and center.
And of course, the whole approval process is neatly tracked in Workflow History.
Access to More Stuff
SPD2010 workflows can access more than just your usual list data. Information contained in User and Organizational Profiles can be accessed, too. This brings up an interesting potential for assigning approval tasks to delegates when a person is out-of-the-office. This is a pretty important capability to have when workflows become heavily used in an organization.
