Before getting into the
details of creating a more elaborate SharePoint 2013 workflow, it is
important to have a good understanding of the basic workflow concepts.
As with anything else, you need to be able to walk before you can run.
Each of the following sections discuss the terminology and description
of key aspects of a SharePoint workflow.
1. Templates
A workflow template is a reusable
workflow solution that has been deployed and installed in your
SharePoint environment. This solution can be available upon
installation or it can be a custom workflow solution created using
SharePoint Designer or Visual Studio. The workflow templates that are
available upon installation need to be enabled, or activated. Upon site
provisioning, some of the workflow templates are activated. For
example, a team site provides the Disposition Approval Workflow and the
Three-state Workflow templates. The provisioning of a publishing site
activates the Publishing Approval Workflow template. You can also
enable these workflow templates by activating their corresponding
features at the site collection or site level.
SharePoint Designer workflows are installed upon
creation and don’t need to be activated. Custom workflows created using
Visual Studio may be deployed using a feature, and therefore may
require activating before use. Use the following steps to check the
feature settings in your site collection (you must be the administrator
of either the site collection or the farm):
1. From the top-level site in your site collection, click Site Actions ⇒ Site Settings.
2. Under the Site Collection Administration section, click Site Collection Features.
3. Ensure that the workflow features have a status of Active.
Associations
A workflow association is a specific
connection between a workflow and a target list, library, content type,
or site. For example, when you add an out-of-the-box workflow to a
document library, you are taking the existing workflow template and
creating a workflow association between the workflow and the document
library.
Workflows can be associated at the following levels in SharePoint 2013:
- Lists/Libraries — By creating the
association at this level, the workflow will run only on items created
within the specified list or library. If you were to save this list or
library as a template, any out-of-the-box workflow templates used would
be associated with the template, making them part of anything created
from the template.
- Content types — By associating the
workflow with a content type, the workflow will run on all items
created with this content type. This enables a reusable workflow
solution if you were to use the specified content type in multiple
lists or libraries.
- Sites — Some workflows aren’t
associated with a list or library, and are triggered by a different
mechanism. Workflows of this nature can be associated at the site
level. The capability to associate workflows with sites means workflow
authors are no longer required to use list and library items. Possible
scenarios for this would be for the workflow to run when the home page
of the site was edited or a new Web Part was added to the page. Only
workflows created with SharePoint Designer 2013 and Visual Studio 2012
can be associated at the site level.
NOTE You
must have the Manage Lists permission to add a workflow to a list,
library, or content type. In most cases, the site administrators or
individuals who manage specific lists or libraries perform this task.
Instances
A workflow instance is an individual
workflow process running on a specific item or site, based on a
specific workflow association. For example, suppose you are using an
approval workflow on a list, and the workflow is set to start on item
creation. When an item is created, the new workflow instance is created.
Forms
Workflow forms enable users to pass
information to a workflow. Examples include prompting the user who
starts the workflow for necessary information in order for the workflow
to run properly. There are essentially two types of forms in SharePoint
2013 workflows:
- Association form — This type of
form provides the opportunity to collect information when the workflow
template is associated with a site, list, document library, or content
type. Only reusable or site workflows will have an association form.
List and document library workflows have no need for an association
form, as they are already associated with a list or document library.
- Initiation form — This type of form allows for the collection of parameters when a new workflow instance is started.
SharePoint Designer 2013 makes it very easy to
create these forms for your workflow. Basically, you tell SharePoint
Designer what parameters you wish to collect, and the rest is taken
care of for you.
Tasks
Workflow tasks are the primary means by
which a user can interact with a running workflow instance. Tasks are
typically assigned to one or more users, and when the user completes a
task, there is a definable outcome. For example, an outcome for an
approval task might be approved or rejected. Workflow tasks have changed significantly in SharePoint 2013, which provides two task actions:
- Assign a Task — Used to assign a task to a single participant
- Start a Task Process — Used to assign a task to multiple participants
Workflow tasks are implemented architecturally as
a content type. In previous versions of SharePoint, a new custom
content type was created each time you created a task. This tended to
clutter up the Content Type gallery, and it was difficult to determine
which content type was your custom task. In SharePoint 2013, there is a
new content type for workflow tasks that greatly simplifies task
creation. The SharePoint 2013 Workflow task content type derives from the Task content type, and provides a column called Task Outcome
that can be used to provide options for completing a task. You can
extend this content type to provide additional options, including
custom task outcomes.
History
Workflow history is a special list that
contains information about what occurred during the execution of a
workflow instance. SharePoint writes information to this list during
execution, and you can too, using the provided Log to History List
workflow action. Writing information to the History list can provide
valuable insight into what happened while your workflow executed.
WARNING There
is a SharePoint Timer Job that periodically deletes older workflow
history items. Although you can disable this job, it is not
recommended, as the Workflow History list can grow very quickly and
cause performance problems if not purged. If you need to keep an audit
trail of what happens during the workflow, create a separate list and
use the Create List Item workflow action to log important workflow
information. Another option is to keep information on the item itself:
If your workflow is associated with a document library, list, or
content type, you can also create a multi-line text column and write
information there. Finally, a tip for you: Be sure to select the Append
Changes to Existing Text option.
2. Creating a Custom Workflow Using SharePoint Designer 2013
The goal of this section is to provide
the administrator with an overview of the workflow capabilities in
SharePoint Designer 2013. The focus is on illustrating how a workflow
is created, the capabilities of the design tool, and how a business
process is modeled.
A very common scenario in most organizations is
some type of change request. This is a good candidate for a SharePoint
workflow. For example, suppose an employee needs new computer hardware
and software for a project. Typically this involves some type of paper
or digital request, followed by an approval process, and then
fulfillment of the request. The following example models such a process
with a custom workflow.
2.1 Virtual Machine Provisioning Scenario
The IT department has decided to
implement a process for managing user requests for infrastructure to be
provisioned using virtual machines. Although an InfoPath forms library
would provide a much richer form authoring experience, for the purpose
of this exercise you will create a simple SharePoint list to capture
user input. The initial input form will contain fields to capture
required information, such as the number of virtual machines, desired
RAM, number of CPUs, and justification and/or reasoning for the new
virtual machine.
The following roles will participate in the workflow:
- requestor — The person making the request
- operations manager — The person who approves/rejects a request
- operations team — The person(s) involved with fulfilling the request
The workflow will contain the following stages:
- Started — During this stage, the workflow will start and perform any necessary initialization functions.
- In Review — During this stage, an operations manager will evaluate the request and determine whether it should be fulfilled.
- Upon entering this stage, the Requestor should be notified via e-mail.
- The Operations Manager should be notified that a new request is awaiting approval via e-mail.
- If the Operations Manager approves the request, it moves into provisioning of the new machines.
- If the Operations Manager rejects the request, it moves to the Rejected stage.
- Approved — During this stage, a member of the operations team attempts to provision the virtual machine(s).
- Upon entering this stage, the Requestor should be notified via e-mail.
- Entering this stage is allowed only if the Operations Manager approves the request.
- In Triage — During this stage, the operations team works to resolve issues that occurred while provisioning the virtual machine(s).
- Upon entering this stage, the Requestor should be notified via e-mail.
- If the issue can be resolved, the request moves back into provisioning.
- If the issue cannot be resolved, the request moves to the Rejected stage.
- Rejected — This stage indicates that the request has been rejected.
- Upon entering this stage, the Requestor should be notified via e-mail why the request was rejected.
- Deployed — Provisioning has completed successfully.
- Canceled — This stage is used to
inform the requestor and operations personnel that issues occurred
during provisioning that could not be resolved.
- Finished — During this stage, the workflow performs any finalization functions and then ends.
Figure 1 illustrates the example workflow.
If during the In Review stage the administrator
rejects the request, the workflow will notify the requestor. If the
administrator approves the request, it moves to the Provisioning stage.
During provisioning, the request is assigned to
an operations manager who can create the new virtual machine(s). If the
virtual machine(s) are created with no issue, then the workflow
completes, and the requestor is notified. If issues are encountered
during the provisioning of the virtual machine(s), the request enters a
Triage stage, during which issues(s) can be resolved by the team. Once the issues are resolved, it will move to provisioning.
Creating Workflow Roles As SharePoint Groups
Before beginning, you need to implement
the Operations Managers and Team roles as SharePoint groups. Perform
the following steps within your site:
1. Create a
SharePoint group called Operations Managers and assign the group
Contribute and Edit permissions. Add members to the group as
appropriate.
2. Create a
SharePoint group called Operations Team and assign the group Contribute
permissions. Add members to the group as appropriate.
Creating the Virtual Machine Request List
Before you create your Virtual Machine
Request Approval workflow, you need to create a list to capture
information for the request. To create the list, perform the following
steps:
1. Navigate to the site that will host your custom workflow.
2. Click the Site Actions icon and choose the Add an app option.
3. On the Site Contents page, choose Custom List.
4. Enter Virtual Machine Requests for the Name of the custom list, and click Create.
5. After the
list has been created, hover over the tile until you see the ellipses
(...). Click the ellipses to reveal a flyout menu, and choose the
SETTINGS option. This takes you to the list’s Settings page.
6. Under Columns, click Create Column.
7. Type Requested By for the Column Name.
8. Select Person or Group for the column’s data type.
9. For “Require that this column contains information,” select Yes.
10. Leave the remainder of the settings for the column at their defaults, and click OK.
11. Repeat the same process to create four additional columns:
- Reason — Type: Multiple Lines of Text, Required.
- Amount of Storage — Type: Number, Required.
- Amount of Memory — Type: Number, Required.
- Number of CPUs — Type: Number, Required.
Now that you have a list to capture the Virtual
Machine Request information, the next step is to create the workflow to
approve the requests.
