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:


•       List


•      Reusable


•       Site


List 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

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.


Site Workflows

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.


Workflow Permissions

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.