If you administer SharePoint 2010 and/or SharePoint 2013 as a Site Owner, Administrator or Support person, you have probably been asked to create one or more workflows to automate a business process. Moreover, if you know what a SharePoint Workflow is and what it can do, you have probably been tagged as “THE” SharePoint workflow expert. Am I right?
As a SharePoint consultant, workflows are one of many ways to illustrate to any business the value of implementing SharePoint in their environment and also is a way to help user adoption by driving people to your site to complete forms or approve requests such as vacation time, expense reports or timesheets.
This is the first article in a series that I will be writing on SharePoint workflows. As the series progresses, I’m going to provide you details about implementing workflows in your environment, walking you through how to develop a workflow to support the approval process for a basic timesheet InfoPath form. But before we dive into building the workflow for that process, you need to understand what workflows are and how you go about implementing them in SharePoint. This series is going to be presented from an end-user perspective. I want to keep the articles at a level that can be used by new, intermediate and advanced users of SharePoint.
What is a SharePoint Workflow?
A SharePoint workflow is simply a series of one or more stages/steps, actions and decisions that perform some automated function inside SharePoint. Think of a SharePoint workflow as a flowchart that has a start and end and also contains decisions, actions and steps that execute in a series or branch one way or the other depending on a decision. Take a look at the flowchart below for the timesheet approval workflow that we will be building over the course of several articles. You can see that this is a pretty simple workflow, but is perfect for you to learn how to use SharePoint workflows.
[click for larger image]
Workflows can be as simple as approving a document before it’s made available to the general audience or as complex as creating a custom workflow for an electronic form to initiate, approve and support a new business project. Workflows are developed inside SharePoint Designer 2010 for SharePoint 2010 or SharePoint Designer 2013 for SharePoint 2013. Visual Studio 2010/2013 can also be used to create very complex workflows, but that is going to be outside the scope of these articles.
Now you know what a workflow is, let’s introduce some Workflow concepts. In SharePoint 2013, there are two versions of the workflow platform available to you – SharePoint 2010 Platform and SharePoint 2013 Platform. Office 365 implementations have both available to you, but in an on-premise implementation of SharePoint 2013, the workflow platform for SharePoint 2013 must be implemented separately. The screen below shows SharePoint Designer 2013’s new workflow dialog, illustrating the two available platforms.
[click for larger image]
For this series of articles, I’m going to be working in the SharePoint 2013 Workflow platform. The 2013 version of the platform has a number of advantages over the 2010 platform. We’ll discuss these in a bit. SharePoint workflows are typically bound to a specific list or library, such as a list to store announcements or a library that stores news articles.
Events, Actions, Conditions and Stages
Events, actions, conditions and stages are the fundamental building blocks of SharePoint workflows. A workflow contains one or more stages, each stage consists of one or more actions and related conditions.
An Event is what triggers the workflow. There are only three events that can trigger a workflow:
An item is created
An item is changed or updated
A site user manually triggers the workflow
[click for larger image]
Conditions are If, Else-If or Else blocks that evaluates a specific piece of information, such as the number of hours worked for an employee, and performs actions based on the evaluation. In the example of evaluating the number of hours worked for an employee, we may reject the timesheet if the number of hours are below 40 or send off an email to their supervisor for approval if hours are greater than 50.
Actions are the basic units of work in a workflow. SharePoint Designer 2013 provides you a variety of actions that you can use in your workflows. Actions are grouped based on their function. The default groups of actions are Core Actions, List Actions, Coordination Actions, Task Actions and Utility Actions. I’ll give you some examples of actions available in each group but a complete reference can be found here.
Core Actions:
Add a comment
Log to History list
Send an Email
List Actions:
Set field in Current item
Create List Item
Delete Item
Coordination Actions:
Start a list workflow
Start a site workflow
Task Actions:
Assign a task
Start a task process
Utility Actions:
Extract substring from start of string
Find intervals between dates
As you can also imagine, there are a number of 3rd party workflows available and you can also have a developer create custom actions for you.
A Stage is a logical grouping for conditions or actions that perform a specific task, such as evaluating the number of hours worked by an employee and determining the actions taken based on that evaluation. Stages can also be broken down further into steps to help further divide a complex stage. Stages are new to SharePoint 2013 and replace the STEP in SharePoint 2010. Stages are much improved over Steps because you have finer control over branching to other Stages and a Stage has a termination point that can be used to perform a specific function (such a log execution of the stage) or can be setup to branch to other stages based on the result of a condition. A workflow must contain at least one Stage and a stage has exactly one entry point and one exit point.
I hope this provided you with a basic understanding of SharePoint workflows and the components that make up a workflow. In the next article, I’ll show you how to get started creating a workflow for our InfoPath Timesheet Form that will evaluate the hours submitted on the timesheet form and based on the number of hours worked, either reject the timesheet or send it onto their supervisor for approval. The Timesheet form will be a separate series of articles that I will provide at a later date.
Author: Eric Stepek, one of Accelebrate’s SharePoint instructors
Eric is a SharePoint administrator, consultant, and instructor with over 28 years of technical experience in a number of industries and performing in a number of different SharePoint roles. He excels at providing real solutions to enhance, augment, and support business objectives instead of trying to change the business process to match the solution.
