Introduction to designing and customizing workflows
Across your enterprise, teams use Microsoft SharePoint sites to collaborate on documents and
share information. You want to build SharePoint solutions that improve the productivity and
efficiency of your organization, but you don’t want to write code. Where do you start?
With Microsoft SharePoint Designer 2010, you can design no-code workflow solutions that
manage simple to more complex business processes in an organization. Workflows add logic to
both system and human processes. Workflows for system processes might update one data
source when another data source changes. Workflows for human processes might send a
document, such as an expense report, to an employee's manager for approval and, if approved,
on to the accounting department for processing.
This is made possible by the powerful yet intuitive workflow editor in SharePoint Designer 2010
that allows nested logic, substeps, and more. For example, if your workflow is associated to a
document library or if it is filtered to the Document content type, a group of contextual Document
Set actions appear. A document set is a new feature in SharePoint Server 2010 whereby a group
of documents are treated as a single unit, so a workflow action for a document set will iterate on all
items in that document set.
Other new workflow actions include actions that form the basis of the three most popular workflows
in SharePoint Server — the Approval, Collect Feedback, and Collect Signatures workflows, utility
actions to manipulate strings and dates; a new relational action that uses the SharePoint User
Profile Store to look up a person’s manager; and new list actions that a workflow can use to set
permissions on a list item.
You can also design and share workflows using Microsoft Visio with its flowchart templates that
can be exported to SharePoint Designer 2010.
This article introduces the basics of workflows. When you understand the types and basic building
blocks of workflows — actions, conditions, and steps — you can quickly add workflows to
automate processes and help improve your organization’s productivity and efficiency.
In this article
What is a workflow?
What type of workflows should I design?
Customize the workflows in SharePoint Server 2010
What are events, actions, conditions and steps?
What are workflow forms?
Where are workflows stored?
Where can I check the status of a workflow?
Suggested next steps
What is a workflow?
Workflows are the way an organization functions, a series of actions that correspond to a work
process, such as the process for purchase orders. SharePoint 2010 helps you automate these
workflows, thereby increasing the efficiency and productivity of the organization. This occurs
because the automated workflows drive the processes so that the organization can focus on doing
work, rather than on managing the processes.
Workflows can control most aspects of a SharePoint 2010 site, list, library, content type, or list
item, including the life cycle of that item. The workflow can include both actions performed by
people (or workflow participants) and actions performed by the workflow. Workflow participants
can interact with the workflow through the designated Tasks list, where a workflow can create a
task for someone and remain paused until the task is marked complete.
Workflows can be as simple or as complex as your business processes require. You can create a
workflow that the user initiates, or a workflow that is initiated automatically based on an event,
such as when a list item is created or changed.
In general, when you use SharePoint Designer 2010 to design a workflow, you follow these basic
Chose the type of workflows you want to create: list, reusable list, or site.
Use the workflow editor to choose and assemble the conditions and actions that define
the steps of the workflow, so that it represents the business process you are automating.
Save and publish the workflow.
Customize the workflow forms that were automatically generated, if necessary.
You can think of a workflow as a flowchart of actions with a beginning, an end, and a sequential
flow from start to finish. Workflows can incorporate parallel branches, but ultimately they progress
from the initial action to the final action.
For example, suppose you were to chart the workflow that routes a document in SharePoint 2010
for approval. When the workflow starts, it automatically notifies the specified reviewer by e-mail
that they have a document to review. The reviewer then reviews the document, and changes the
status of the document to indicate that they have completed their task, and whether they have
approved or rejected the document. Based on the reviewer response, the workflow proceeds down
one of two parallel branches. If the reviewer approves the document, the workflow moves the
approved document to a specific document library, and then sends an e-mail message to the
entire team notifying them of the approved document. If the reviewer rejects the document, the
workflow notifies the document author of this. In either case, the workflow then reaches its end and
the process is completed.
Diagram 1: Example approval workflow
TOP OF PAGE
What type of workflows should I design?
There are three types of workflows in SharePoint 2010:
A list workflow is the type of workflow that was available in SharePoint 2007. Because it has the
context of the list for which it was created, list workflows automatically have access to the values of
the custom fields for the list item on which they will run, such as the custom Notes field for a
document library. List workflows cannot be made available to other lists or libraries on this or other
sites. To have the same workflow functionality for multiple lists you must manually recreate the
workflows in all locations.
If you know that you will only need the workflows you are designing for a specific list, the list
workflow has the advantage of automatically making available the custom fields of the lists.
Reusable List Workflows
You can create a reusable list workflow (reusable workflow) in the top-level site in the site
collection, and that workflow can be made globally reusable — meaning that the workflow can be
associated to any list, library, or content type in the site collection. You can also create a reusable
workflow in any subsite in the site collection; this workflow is available for reuse in that particular
You can also export a reusable workflow from one site and then upload and activate that workflow
in a different site. For example, you can create a reusable workflow in a test environment, test it,
and then export it to a production environment. SharePoint Designer 2010 supports exporting a
workflow as a template.
Reusable workflows, by default, don’t have the context of a specific list or library. Therefore, by
default, they provide only the columns that are common across lists and libraries, such as Created
and Created By.
If your reusable workflow requires certain columns to be present in the list or library that you
associated it to, you can add those columns as association columns. Association columns get
added automatically to a list or library when a reusable workflow is associated to that list or library.
When you create a reusable workflow, you can alternatively choose to filter your reusable workflow
to a specific content type. This enables you to work with the fields of the content type in
SharePoint Designer 2010. For example, if a reusable list workflows is associated with the
Document content type, you view and use in your workflow fields that are specific to the content
type, such as Document ID. Then, in the browser, you can associate your reusable workflow either
to a specific content type or to any content type that inherits from that content type. If you
associate a workflow to a site content type, you make that workflow available for all items of that
content type in every list and library on the site to which that content type has been added. You
can even make it available for sites in a collection if the workflow is configured to be a Globally
If you want users to be able to use the workflows you are designing on multiple sites, lists,
libraries, and content types, a reusable workflow will probably best meets your needs. We expect
that most workflows for SharePoint 2010 will use reusable workflows.
A site workflow is associated to a site — not to a list, library, or content type. So unlike most
workflows, a site workflow is not running on a specific list item. Because of this, many of the
actions that are available for items not available for site workflows.
In the browser, you start a site workflow or view the status of running site workflows by clicking the
Site Actions menu, click View All Site Content, and then clicking Site Workflows.
If you want to create a workflow, but don’t need a list, library, or content type for the workflows, a
site workflow will probably best meet your needs. For example, you can create a site workflow as a
way for people to provide feedback about your site.
Customize the workflows in SharePoint Server 2010
You don’t need to start from scratch to design workflows that match the processes of your
organization. The four most popular workflows in SharePoint Server 2007 — the Approval, Collect
Feedback, Collect Signatures, Publishing Approval workflows — have been completely rebuilt as
declarative reusable workflows, meaning that they are now fully customizable in SharePoint
Designer 2010. You can copy and modify (recommended) or edit these workflows, as well as
custom reusable workflows, to meet the needs of your organization.
NOTE There are additional workflows in SharePoint 2010, such as the Three State workflow,
but they are not declarative workflows, and therefore cannot be modified.
These workflows are event-driven, and all of the important events in the workflow are surfaced in
the workflow editor, both for each task in the process and for the process as a whole. For example,
you can easily add conditions and actions to define what happens when each task is assigned,
expired, or completed.
What are events, actions, conditions and steps?
These are the building blocks of a workflow. A workflow consists of one or more steps, and each
step consists of actions and any associated conditions. Each workflow is initiated by an event.
WHAT ARE EVENTS?
An event is what starts or initiates a workflow. Events can also be used to manage the timing of
actions within a workflow, such as waiting for the status of an item to change. There are three
events that can start a workflow:
An item is created.
An item is changed.
A workflow participant clicks a start button on the SharePoint site.
NOTE Site workflows can only be started manually.
You can create a workflow that a participant starts manually, or a workflow that is started
automatically when a list item is created or changed. For example, you want to configure your
custom Design change request approval workflow so that it can be started manually and when
an item changes, but not when an item is initially created. On the settings page for the workflow, in
Start Options, select Disable automatic start on item creation.
When a workflow participant starts a workflow manually, that person first browses to the list or
library that the workflow is attached to. Any person with at least the Contribute permission level
can initiate a workflow that is designed to start manually. To start the workflows manually, the
participant clicks an item, clicks Workflows on the menu, and then chooses a workflow from a
page that displays all workflows available for that item. The participant fills out a workflow initiation
form, if necessary, and then initiates the workflow by clicking the start button on the form. Initiating
a workflow creates a new instance of that workflow for that specific item.
NOTE The Workflows command is available only when the item is in a list, library, or is of a
content type that has at least one workflow attached to it.
For a workflow that is started manually, the initiation form can be as simple as the image on the
left, or more complex, such as the image on the right.
More complex form
You can also add custom fields to an initiation form when you design the workflow. Workflow
participants can then provide information to the workflow by filling out this form, and those settings
are passed to the workflow. A new workflow instance starts, and that workflow can then look up
and use the information provided through the form at any point in the workflow. You can also
specify the fields that will be used in an association form for reusable workflows.
WHAT ARE ACTIONS?
An action is the most basic unit of work in a workflow. SharePoint Designer 2010 provides a set of
ready-made, reusable actions for you to incorporate into your workflow. For example, your
Create, copy, change, or delete list items (including documents).
Check items in or out.
Send an e-mail message.
Create a task for someone on the Tasks list of your team site.
Collect data from a participant that can be referenced later in the workflow.
Pause or stop the workflow.
Log workflow information to a History list to use for repudiation or workflow debugging.
Set workflow variables or perform calculations.
SharePoint Server 2010 includes three new task actions: Start Approval Process, Start Feedback
Process, and Start Custom Task Process. The “big three” workflows included in SharePoint Server
2010 — the Approval, Collect Feedback, and Collect Signatures workflows — are built with these
actions. The approval actions surface all of the important events in an approval process, making it
easy for you to design a human workflow process where many people interact or collaborate on a
A workflow can contain any number of actions. The actions just listed are performed by the
workflow, but other actions might be performed by workflow participants. For example, in an
approval workflow the act of actually reviewing and approving the document is done by a workflow
participant. Actions done by a workflow participant are represented by tasks assigned to that
person in the designated Tasks list. The five actions in Diagram1: Example diagram workflow, near
the beginning of this article, are:
Send an e-mail message to notify the reviewer
Review the document (a task assigned to a workflow participant)
Move the document to the Approved document library
Send an e-mail message to notify the team
Send an e-mail message to notify the document author
In the most basic sense, when you design a workflow, you identify the necessary sequence of
actions, and then you assemble that sequence of actions by using the workflow editor. For
example, in Diagram 1: Example approval workflow, the first action that you want is to send an e-
mail message to notify the reviewer.
So in the workflow editor, you click the first step, type some or all of email and choose Send an
WHAT ARE CONDITIONS?
When you design a workflow, you can use the workflow editor to create rules that apply conditional
logic to SharePoint sites, lists, items and content types. A rule establishes a condition where the
workflow performs the associated action only if that condition is true. For example, you can create
a rule where the workflow sends a reviewer an e-mail message only if an item is created by a
specific person. You can also add multiple conditions per branch. For example, you can create a
rule where a reviewer is sent an e-mail message only if an item is both (1) created by a specific
person and (2) the document title contains specific keywords. Finally, you can associate multiple
actions with one condition. For example, you can create a rule where if an item is created by a
specific person, then (1) the reviewer is sent an e-mail and (2) workflow information is logged to
the History list.
To sum up, a rule is one or more conditions associated with one or more actions: If all clauses in
the condition are true, do all the associated actions.
In the previous example, the user specified a set of two conditions and a set of two actions for the
workflow. However, you can create multiple branches in the workflow: If condition A is true, do one
action; if condition B is true, do a different action. To add a branch to a step, click Insert Else-If
Branch. For example, in the approval workflow, if the reviewer approves a document, the workflow
performs one a series of actions; if the reviewer rejects a document, the same workflow performs a
different action. This is a conditional branch.
In the workflow editor, this step has two branches and looks like the following.
You can also create a branch that does not have a condition. This way, the workflow performs one
action if a condition or set of conditions is true and a different action if they are false. For example,
the following step in a workflow sends a message to the Approvers only if the condition is true;
else, the workflow sends a message just to the workflow initiator. By adding a branch without a
condition, the workflow performs the action in that branch in any case where the condition in the
first branch is false.
NOTE To have a branch without a condition, it must be the last branch in the conditional block
and not the only branch in the in the conditional block.
NOTE Branching in a workflow cannot extend from one step to another. A set of 'Else If'
branches, also referred to as a conditional block, is always contained in a single step. You can,
however, nest steps as substeps.
SharePoint Designer 2010 provides several ready-made, reusable conditions for you to
incorporate into your workflow. For example, you can specify that the workflow performs the
associated actions only if an item:
Is created or modified in a specific time span.
Is created or modified by a specific person.
Has a title field that contains specified keywords.
Is a file of a specific type or has a file size in a specific range. (This condition is available
only when the workflow is attached to a document library.)
For more information about the conditions available in SharePoint Designer 2010, see Workflow
conditions in SharePoint Designer 2010: A quick reference guide.
In addition, you can create custom conditions and advanced conditions in SharePoint Designer
2010 where you can specify a wide range of parameters. With custom conditions, you can
compare a field in the current list with a value. For example, you can create a custom condition
where if the Approval Status field equals Approved, do the associated action. With advanced
conditions, you can compare one value to another value. This allows you to create a comparison
between a field in any list and a value from another list. For example, you can create an advanced
condition for the Shared Documents library where if the value of the Status field in the Tasks list
equals Pending, do the associated action.
NOTE An action does not require a condition. For example, the first step in Diagram 1: Example
approval workflow, near the beginning of this article, sends an e-mail to notify the reviewer. This
action does not have a condition associated with it. A parallel block of actions also does not
require a condition.
PARALLEL VS. SERIAL ACTIONS
When you have more than one action associated with a condition, the actions can be set up to run
at the same time (parallel) or one after another (serial), the default.
Serial actions For example, in the following workflow, you can set up two actions so that when a
document is approved, the document is copied to the Archive document library and then
(afterwards) a message is sent. In the workflow editor, then indicates that the second action
occurs after the first.
Parallel actions For example, in following workflow, you can set up two actions so that when a
document is approved, a message is sent and (at the same time) the document is copied to the
Approved document library. In the workflow editor and indicates that the second action occurs at
the same time as the first. This is particularly helpful with tasks and actions that take significant
time. For example, in the case of tasks, it can be used to control when tasks are assigned.
NOTE Parallel actions are not absolutely simultaneous; the exact order cannot be specified and
may vary each time the workflow runs.
In a rule (conditions and actions), actions can occur in series, in parallel, or in a
combination of series and parallel.
A set of serial or parallel actions must be contained within a single step.
WHAT ARE STEPS?
A workflow is comprised of one or more steps. Each step can contain numerous actions and
associated conditions. You can even nest steps within other steps. You might do this to help
organize your workflow. You can think of steps as blocks of functionality in the workflow editor. For
example, the following workflow has two steps, as shown in the workflow editor.
Steps allow you to group conditions and actions so that one set of rules (conditions and actions)
can be evaluated and performed before a second set.
Configure actions in a workflow to run using the permissions of the workflow author. In SharePoint
Designer 2010 you can use impersonation steps to have the workflow perform actions by
impersonating the workflow author instead of the workflow initiator. Impersonation steps are
especially useful in approval and publishing scenarios, where the people submitting content for
approval and the people approving content have different permissions.
The workflow author is the last person who published the workflow. When a workflow is
republished by a different user, the workflow author doesn’t change for in-progress instances of
the workflow. Instances of the workflows that are started after the workflow is re-published will use
the updated workflow author.
NOTE Impersonation steps can only be added to the root of a workflow and cannot be nested in
In the following scenario the person initiating the workflows does not have the permissions to add
a file to the Archive library, but the workflow author does. When the person initiates the workflow, if
the condition evaluates as true in the impersonation step, then the document is copied to the
Archive library using the permissions of the workflow author. Step 2 is not an impersonation step,
therefore it runs as the workflow initiator. It is a best practice to only use impersonation steps for
minimal set of actions that require the permissions of the workflow author to succeed.
One step or many? Some workflows can be designed either as a sequence of actions within one
step or as a sequence of steps. For example, the actions in the following step could be broken out
into separate steps or nested with the conditional block as separate steps
Following is an example of the process using nested steps in a conditional block.
Steps are a way to organize your workflow. Exactly how you use steps in your workflows is, to a
great degree, up to personal preference. For example, a workflow might have many actions in a
step that doesn't use conditions. In this case, you might want to separate the actions into steps just
to better organize them. The rules in one step are processed to conclusion before going on to the
next step, so you want to group in the same step rules necessary to effect the specific action or
actions that you want.
TOP OF PAGE
What are workflow forms?
To make your workflow more dynamic and flexible, you can add a form to the workflow. With a
form, you can collect information from workflow participants at predefined times in the workflow,
and make it possible for participants to interact with the tasks for that workflow, and help ensure
data is available for reusable workflows regardless of what list, library, or content type it is
With SharePoint Designer 2010, you can create three types of workflow forms:
An initiation form gathers information from the workflow participant when they start the
workflow. It is automatically generated when you create the workflow in SharePoint Designer 2010.
Initiation forms are displayed to users when they manually start a workflow on a given SharePoint
item. With an initiation form, users can specify additional parameters or information about the
workflow as it applies to the given SharePoint item. For example, you might use an initiation form
to ask who should review a document and by when the review should be completed. SharePoint
Designer 2010 automatically generates an InfoPath or ASP.NET initiation form according to your
initiation specifications. If no initiations parameters are required, the form will only have Start and
A custom task form allows workflow participants to interact with tasks in the Tasks list
specified for the workflow. With the Custom Task Wizard, you can easily create custom form fields
and add them to a custom task form. When you finish designing the workflow, SharePoint
Designer 2010 automatically generates the InfoPath or ASP.NET forms for your custom tasks.
Then, when the workflow runs and tasks are created, the user browses to the Tasks list specified
for the workflow, marks the task as completed, and enters any optional or required information
specific to the workflow. The workflow can then respond to those changes as specified in the
workflow, or look up and evaluate that information in later steps of the workflow.
A reusable workflow, by default, only provides the fields common to all items, such as
Created and Modified by. This is because a reusable workflow isn’t by default associated with a
list, library, or content type. An association form enables you to associate fields with a reusable
workflow so that the fields will be available when you design and run the workflow.
After SharePoint Designer 2010 automatically generates the forms, you can customize them by
going to the settings page for the workflow, in the Forms section, click the form you want to
customize. Workflow forms are either InfoPath or ASP.NET pages. They are stored on the
SharePoint site with the workflow source files.
ENHANCED FUNCTIONALITY WITH INFOPATH 2010 FORMS ON SHAREPOINT
If your server is running SharePoint Server 2010 (not SharePoint Foundation 2010 alone), the
workflow forms — the association, initiation, and task — are now InfoPath 2010 forms. It is easy to
change the appearance and layout of InfoPath forms, and you can add validation rules to an
InfoPath form. To edit a workflow form in InfoPath 2010, just click the form and InfoPath opens the
form directly from SharePoint Designer 2010.InfoPath forms are available for lists, libraries and
TOP OF PAGE
Where are workflows stored?
Workflows are stored in a site-level document library called Workflows. This document library is
created automatically by SharePoint Designer 2010. By default, the Workflows document library is
hidden from the browser and has no List Views, such as AllItems.aspx or EditForm.aspx. To view
the contents of the workflows library, in SharePoint Designer 2010, in the Navigation pane, click
All Files, and then click Workflows in the main pane.
You may not be able to view workflows using All Files, It depends on how the server is
The primary way to access and design workflows in SharePoint Designer 2010 is to click
Workflows in the Navigation pane.
The workflows document library contains a folder for each workflow created with SharePoint
Designer 2010. The folder contains the source files necessary for the workflow, such as:
The workflow markup (.xoml) file.
The workflow configuration file.
InfoPath xsn or ASP.NET aspx forms needed for the workflows, such as initiation forms
(for workflows that are started manually) or custom task forms.
To edit an existing workflow in SharePoint Designer 2010, in the Navigation pane, click
Workflows. In the main pane, right-click the desired workflow, and click Edit Workflow.
To copy and modify a reusable workflow in SharePoint Designer 2010, in the Navigation pane,
click Workflows. In the main pane, right-click the desired reusable workflow, and click Copy and
Both of the preceding procedures open the workflow in the workflow editor. You can click on the
ribbon or the breadcrumb navigation to edit the workflow, manage settings, and define the task
process for the workflow.
The workflow editor provides an action called Log to History List. It is a best practice to use this
action in your workflows to keep a record of the workflow history. Workflows history is invaluable
for investigating errors or for tracking and repudiation purposes.
When you create a workflow that uses the action Log to History List, SharePoint Designer 2010
automatically creates a list called Workflow History. The list is by default created at
http://<sitename>/Lists/Workflow%20History. You can specify to create a different history list when
you design a list or site workflows and when you associate a reusable list workflow. This list has
columns for such information as user ID, date, event, and error description. Like the Workflows
document library, by default the History list is hidden from the browser but can be seen in
SharePoint Designer 2010, in the Navigation pane, by click All Files.
The workflow editor provides six actions that interact with the Tasks list, including Assign a To-Do
Item, Collect Data from a User, and Assign a form to a Group. Workflows use the Tasks list by
default, but can be configured to use a custom Tasks list. You might use a custom Tasks list to
separate workflows tasks from other types of task or for permissions related issues. You can use
one custom Tasks list for all workflows on the site or a custom Tasks list for each workflow. It
depends on the technical and organizational requirements for the workflows.
When you create a workflow that uses any of preceding three actions, SharePoint Designer 2010
automatically creates the form, the content type for the task, and the Tasks list, if necessary. By
default, the Tasks list can be viewed in the browser, unlike the Workflows document library and
Workflow History list.
TOP OF PAGE
Where can I check the status of a workflow?
You can easily view the progress of workflows on a selected item through the browser. The All
Items view of a list or document library displays, by default, the current status of workflows running
on an item. In the following example, the Design Change Request workflow is In Progress for
the Widget 1 DCR.
There will be multiple columns if multiple workflows are associated with the list or library.
The columns can be removed from the All Items view without affecting the functionality of
The status column will not be added to the view if there are already six or more
lookup\status columns in the view.
Clicking the status of the workflow for an item, such as In Progress or Completed, will take you to
the Workflow Status page for the workflow for the specific item. To see the status for site
workflows, click the Site Actions menu, click View All Site Content, and then clicking Site
Workflows. The workflow status page provides you with information about:
Who initiated the workflows and when for the item
Tasks associated with the workflow for the item
History for the workflow for the item, such as when the workflows was initiated and when it
You will also see a workflow visualization for the status of the workflow if the:
Show workflow visualization on status page option was selected in SharePoint
Designer 2010 when the workflow was published
Computer from which the workflows was published had Visio Premium 2010 installed
Workflow is running on SharePoint Server 2010
Visio Graphics Services is running on the server
NOTE Visio does not need to be installed to on the local computer to view the workflow
With workflow visualization, a Visio diagram of your workflow is automatically created and
displayed in a Visio Web Part on the Workflow Status page. The workflow visualization shows a
“live” view of where a specific workflow is at.
To view the Workflows page for an item you can also click the item in the list, and then click
Workflows on the menu.
NOTE The Workflows command is available only when the item is in a list or library that has at
least one workflow attached to it.
When a user starts a workflow on an item SharePoint Foundation 2010 or SharePoint Server 2010
adds a new column to that list or library the item is in. By default, the column name matches the
name of the workflow. This read-only column displays the current status of the item within that
workflow. This status column is added automatically for each workflow the first time it is run.
In each column, the workflow status is a link. When you click In Progress, for example, you see
the Workflow Status page for that instance of the workflow.
TOP OF PAGE
Suggested next steps
Workflows are a powerful way to add application logic to your SharePoint sites and applications.
Now that you understand workflow basics, you might want to get started by creating a workflow.
Find more information about designing and customizing workflows in the See Also section.
TOP OF PAGE
Understand approval workflows in SharePoint 2010
Use the task process editor for approval workflows
Workflow actions in SharePoint Designer 2010: A quick reference guide