CHAPTER 8 SharePoint Designer Workflows
Workflows are one of the great features of SharePoint Online and are generally favored by power users (end users with some technical know-how) because of the ability to quickly automate business processes without the need for programming knowledge or IT involvement.
SharePoint Designer 2010 introduces a new workflow designer that makes the process of creating workflows intuitive and fairly painless. The process of creating a workflow has become less about “learning SharePoint Designer” and more about mapping out the logic for the workflow and making sure it accurately reflects the business process(es) you’re trying to automate.
In this chapter, we’ll cover the following topics:
• Introduction to Workflows in SharePoint Online
• A Quick Tour of SharePoint Designer
• Building and Deploying a Simple Workflow
• Integration with Microsoft Visio 2010
• Developing Custom Workflow Actions in Visual Studio
Introduction to Workflows in SharePoint Online
Let’s start by covering some workflow basics. If you’re new to workflow development or could use a refresher on the topic, this section will quickly get you up to speed on key concepts that are critical to understanding the rest of this chapter.
What Is a Workflow?
A workflow can be described in a very general sense as a series of tasks that produce an outcome. In the context of SharePoint Online, we can define a workflow more narrowly as the automated movement of documents, items, or information through a sequence of actions or tasks that are related to a business process. In other words, workflows allow us to apply automation to business processes.
Note The terms workflow and business process are often used interchangeably. In this chapter, we’ll keep the two terms separate for the sake of clarity. When we say workflow we’re talking specifically about automation applied to a business process in SharePoint Online.
Workflows in SharePoint Online have a beginning, an end, and a sequential flow of logic that progresses from start to finish. It’s possible for workflows to execute tasks in parallel (using a structure called a parallel block), but they still ultimately progress sequentially from start to finish (an initial state to a final state).
Modeling a Workflow
A workflow is typically modeled (visually represented) using a flowchart, which is a natural fit because it has a beginning point, an end point, and a flow of actions and conditions in between. SharePoint Online and SharePoint Designer are both aware of this and have built-in capabilities that let us view and work with our workflows as flowcharts. You’ll learn more about those capabilities later in this chapter when we start building workflows.
Types of Workflows
SharePoint Online supports three types of workflows:
A list workflow is one that is associated with a specific list (or library). Because it operates in the context of a specific list, it automatically has access to any custom fields that exist on that list. It cannot be associated with any other lists, however, so using it elsewhere means having to manually create another, separate instance of it. Therefore, a list workflow probably isn’t the best choice if your workflow needs to operate on multiple lists or operate at the site level. (To be fair, there are some creative ways to “copy” list workflows from one list to another that you can find out on the Internet by searching on the topic. However, SharePoint Designer provides no built-in, supported way to do it.)
Reusable workflows are associated with a content type rather than a specific list. If they’re published to the top-level site of a site collection, they’re said to be “globally reusable” because they’re available across the entire site collection.
Reusable workflows can also be exported from one site and then imported into another, providing a means to accomplish tasks such as migrating a workflow between environments (such as from test to production).
Because reusable workflows are associated with a content type rather than a specific list, the way we work with them in SharePoint Designer is a little different (especially if you choose to associate your workflow with all content types, which is one of the options when creating it).
A reusable workflow is a good choice if you’re creating a workflow that will be used on multiple lists or in multiple sites.
A site workflow is exactly what the name implies: a workflow that operates on a site and not within the context of any list, library, or content type. One “side effect” of this difference in scope is that many of the actions available to the other workflow types are not available to site workflows because they don’t apply when not working with list items.
Site workflows are a good choice when you need to create a workflow that doesn’t operate in the context of a specific list, library, or content type.
Workflow Building Blocks
The building blocks of a workflow are actions, conditions, and steps.
Actions are what actually do the “work” in a workflow. SharePoint Designer includes a set of built-in actions such as Send an Email and Copy List Item that you can use in your workflows.
Conditions control the flow of execution in a workflow by executing actions only when a given statement about something is true. For example, there’s a condition called Created by a Specific Person that lets you execute a set of actions only when a list item was created by the person you specify.
Steps provide a way to logically organize a workflow into related sets of actions and conditions. Strictly speaking, you could put your entire workflow into a single step, but it’s often more beneficial (in terms of readability and maintenance) to use multiple steps unless the workflow is extremely short.
SharePoint Designer provides a fairly robust set of built-in actions you can use in your workflows. However, if you need more, it’s possible to build custom actions in Visual Studio 2010, deploy them to SharePoint Online, and then use them within SharePoint Designer. You’ll learn more about that in the “Developing Custom Workflow Actions in Visual Studio” section later in this chapter.
How Are Workflows Started?
Workflows are started (initiated) by events. There are three types of events that can start a workflow in SharePoint Online:
• An item is created
• An item is changed
• The workflow is manually started
Initiation of the workflow is automatic in the case of the first two events.
Note Site workflows cannot be started automatically because they’re not tied to an item in a list or library. They must always be started manually.
The workflow settings page in SharePoint Designer provides a set of start options that let you configure how your workflow can be started. You’ll learn more about the workflow settings page in the section titled “A Quick Tour of SharePoint Designer” coming up shortly in this chapter.
By default, the actions in a workflow execute with the permissions of the user who started the workflow (the workflow initiator). There is, however, a special type of step called an impersonation step that lets a workflow execute actions with the permissions of the workflow author. The workflow author is considered to be the last person who published the workflow. If a workflow is republished by a different user, the workflow author will not change for any in-process workflows; only for new instances that begin after the workflow was republished.
Note Impersonation steps can be added only to the root (outermost level) of a workflow. They cannot be nested within another step.