Since the very first version of SharePoint, workflows have always been an important feature for the platform as a whole. This is due to the fact that for a long time, companies have found workflows indispensable for automating business processes. Over the years, in the various versions of SharePoint, workflows have become more powerful, flexible, customizable, and easier to create. However, some criticism remained regarding the performance and scalability of SharePoint workflow services. As an administrator, you will be happy to learn that these issues have been addressed in SharePoint 2013.

The architecture of the workflow platform for SharePoint 2013 has been changed quite dramatically compared to what it is in SharePoint 2010. First off, the old SharePoint 2010 workflow platform is still available in SharePoint 2013, but there’s also a new workflow platform available that is based on .NET 4.5.

Note Workflows hosted in SharePoint 2013 and built using the old SharePoint 2010 workflow platform are typically called SharePoint 2010 workflows, while workflows created using the new workflow platform introduced in SharePoint 2013 are called SharePoint 2013 workflows. Both terms are a bit misleading: SharePoint 2010 workflows can actually run in SharePoint 2013, not just in SharePoint 2010. And it can be argued that, as you’ll soon find out, SharePoint 2013 workflows don’t run in SharePoint at all. Never mind its shortcomings, make sure you’re familiar with this terminology.

The new workflow platform allows you to take SharePoint workflows and actually run them outside of your SharePoint farm. Taking SharePoint features and run them outside of the SharePoint farm is a general trend in SharePoint 2013, you will see the same in other SharePoint 2013 technologies such as Office Web Apps and the new SharePoint App model. This is a good thing, since this reduces the surface of custom programs that negatively impact the stability and performance of your SharePoint farm. Architecturally, this is a huge break from previous SharePoint platforms.

Other than the biggest eye catcher, meaning the architectural changes mentioned, the SharePoint workflow platform offers more new improvements, which will all be discussed in the rest of this blog post.

Best Practices The old SharePoint 2010 workflow platform is still available in SharePoint 2013 for compatibility reasons and is based on the Windows Workflow Foundation (WF), included with the .NET 3.5 framework. However, it is recommended to base new custom workflow efforts on the new model.

Workflow Architecture

In this section, we will give you an overview of the new workflow architecture platform and discuss which things are changed regarding workflows in SharePoint 2013. With the arrival of SharePoint 2013 the architecture of the workflow platform has completely changed. In SharePoint 2010 the workflow platform was an integrated part of SharePoint itself, running within the SharePoint farm. The .NET 3.5 Workflow Foundation Runtime was hosted by SharePoint 2010, which acted as the so-called custom workflow service host. In SharePoint 2013, this is absolutely not the case, as the workflow host provider is taken out of the SharePoint farm altogether.

Before delving into this new architectural change, it might be comforting to know that SharePoint 2013 keeps hosting the 2010 workflow platform, so every SharePoint 2010 workflow will still work in SharePoint 2013.However, the new 2013 workflow platform will not be hosted by SharePoint at all. Instead, the new workflow execution host (or workflow server) is Windows Azure Workflow (WAW). We have to be real careful here, as the name WAW implies that such workflow execution hosts run in the cloud which doesn’t have to be the case, and most of the times are not. On premises SharePoint farms use workflow servers that are real machines running on premises as well. As a matter of fact, on premises SharePoint deployments only work with on premises workflow servers running WAW. As of yet, they are not able to leverage Azure based WAW servers. Opposed to that, Office 365 does leverage Azure based WAW servers.

Note This is another trend you will see frequently in SharePoint 2013: whenever possible, SharePoint 2013 will offer built-in cloud support.

This new SharePoint 2013 workflow model is based on Windows Workflow Foundation 4.5 (WF), part of the .NET framework 4.5, and is substantially redesigned compared to earlier versions. Not only are SharePoint 2013 workflows powered by Windows Azure Workflow, a powerful new workflow service part of the .NET 4.5 framework, Windows Azure Workflow itself is built on Windows Workflow Foundation 4.5. In its turn, Windows Workflow Foundation makes extensive use of the messaging functionality provided by Windows Communication Foundation (WCF).

Note Windows Workflow Foundation is a technology that makes creating workflows within .NET easy. It provides a workflow API, an in-process workflow engine, as well as a rehostable workflow designer. Windows Communication Foundation is a set of application programming interfaces (APIs) that can be used for building connected, service-oriented applications (SOAs). Essentially, SOAs are applications that deal with exchanging messages. As is the case with WF, WCF is also a part of the .NET framework.

You can use workflow models to give structure to business processes. To put it in other words, a workflow is a representation of a business process. In Windows Workflow Foundation 4.5, each workflow consists of a structured collection of workflow activities. Each activity represents a functional component of a business process, such as sending an e-mail message, checking out a document located in SharePoint, or logging information to a SharePoint history list.

The Windows Workflow Foundation 4.5 activity model is adopted by SharePoint 2013 to represent SharePoint-based business processes. Another concept you will find in SharePoint workflows is the concept of conditions, which are indispensable decision makers that will allow workflows to behave intelligently and decide which activities need to be executed. Examples of conditions are: if x happens do something, wait until time to perform an operation, as long as is true do nothing. Most often, conditions in SharePoint workflows rely on some type of information about a document in a SharePoint document library or a SharePoint list item.

As a new addition to activities and conditions, SharePoint 2013 provides a new stage model. Stages provide a convenient way to group conditions and activities together and now are the building blocks for the new recommended best practice surrounding the construction of workflows that don’t have fixed execution paths, replacing the old and deprecated state workflow model.

Note Workflows can be sequential where the order of the execution path is fixed. State workflows are event driven and their execution paths are determined by external factors.

A final concept you will need to know about is workflow actions. So far, we have only talked about workflow activities, but it is also important to know the difference between workflow activities and workflow actions. Workflow activities are a lower level concept and represent the underlying managed objects whose methods drive workflow behaviors. Workflow developers will interact with workflow activities via code or using a specific development environment. Workflow actions, on the other hand, are wrappers that encapsulate the underlying activities and present them in a user-friendly form in SharePoint Designer 2013 or Visual Studio 2012 (more about these tools later). When you create a workflow you will work directly with workflow actions. At the level of the workflow execution engine, the engine acts directly on the corresponding activities.

Workflow activities, which are implementations of activity classes, are implemented declaratively by using XAML. Workflow activities are invoked using loosely coupled web services that use messaging APIs to communicate with SharePoint. These APIs are built on the messaging functionality that is provided by Windows Communication Foundation (WCF). The messaging framework is very flexible and supports virtually any messaging pattern that you need. Within your SharePoint 2013 farm, Windows Workflow Foundation and WCF are hosted in a component called the Windows Azure Workflow Manager Client server (located on premises, or, for Office 365, in the cloud), so that is also the place where the workflow activities actually run.

Note XAML is a declarative XML-based language for describing structures such as Windows Presentation Foundation (WPF) user interfaces, or, in this case, workflows.

Figure 1 depicts a high-level view of the SharePoint 2013 workflow framework. Notice, first, how the new workflow infrastructure introduces the Windows Azure Workflow Manager Client as the new workflow execution host (denoted in the Figure as Azure Workflow). Whereas in previous versions workflow execution was hosted in SharePoint itself, this has changed in SharePoint 2013. Workflow Manager Client is external to SharePoint and communicates using common protocols (REST API calls over HTTP or HTTPS) over the Windows Azure service bus, mediated by OAuth 2.0.

Note OAuth is a security protocol that allows applications to communicate with other applications, if need be across domains, without actually sharing user credentials. As a best practice, communication between such applications will be over HTTPS, to ensure all OAuth tokens are sent safely across the network.

Other than that, the architectural overview contains no big surprises; the SharePoint “box” contains the features that you would expect to see: content items, events, apps, and so on. As promised before, notice that there is also an implementation of the SharePoint 2010 workflow host (that is, the Windows Workflow Foundation 3.5 engine). It’s there for backward compatibility reasons.

Let’s take a further moment to define the major workflow related components found on Figure 1:

• Windows Azure Workflow Manager Client server (or, as it is called in the Figure, just Azure Workflow) takes care of managing the workflow definitions and is responsible for hosting the execution processes for workflow instances.
• SharePoint 2013 provides the framework for SharePoint workflows, which model SharePoint-based business processes that involve SharePoint documents, lists, users, and tasks. Additionally, SharePoint workflows, associations (where SharePoint workflows are tied to SharePoint entities such as lists, libraries, sites or content types), activities, and other workflow metadata are stored and managed in your SharePoint 2013 farm.
• SharePoint Designer 2013 is a tool for creating, designing, and publishing workflows. Because of its ease of use, the main target audience for this tool consists of power users.

Figure 1 SharePoint 2013 workflow architecture.

The Workflow Manager Client needs to be present on every SharePoint machine running workflow services and sits on top of the Workflow Manager Client Service Application Proxy (also shown in Figure 1). The Workflow Manager Client allows SharePoint 2013 to communicate and interact with the Workflow Manager Client server. Server-to-server authentication is provided using OAuth 2.0 (hence the Azure Access Control component). The various SharePoint events to which a SharePoint workflow can be listening, like itemCreated, itemUpdated, and so on, are routed to Workflow Manager Client using the Windows Azure service bus. For the return trip, the platform uses the SharePoint Representational State Transfer (REST) API to call back into SharePoint.

Note A service bus is a software architecture model used in SOA architectures to describe a piece of software that facilitates interaction and communication between various distributed applications. As such, it is a more advanced form of client/server architecture models, which are typically used in heterogeneous and complex infrastructures. REST can be seen as a light version of SOAP. The REST protocol leverages the HTTP protocol and allows clients to interact with server resources in various ways, supporting HTTP verbs such as GET, POST, PUT, and DELETE.

There are additions to the SharePoint workflow object model that allow you to manage and control workflows and their execution by interacting with the Workflow Services Manager. These additions are also known as the Workflow Services Manager object model and are part of the bigger all-encompassing SharePoint 2013 object model (as can be seen in Figure 1).

Note Typical reasons to leverage the Workflow Services Manager object model are related to workflow deployment, messaging, instance control, and interoperability with SharePoint 2010 workflows. A new and interesting feature of the Workflow Services
Manager is that it allows 3^rd party vendors to create separate workflow designers that leverage it and build a new UI to create workflows, and offer such separate workflow designers to the audience in the form of SharePoint Apps.

Workflow authoring can be done in various ways. SharePoint Designer, in its 2013 version, can now be used to create and deploy both SharePoint 2010 and SharePoint 2013 workflows, and Visual Studio 2012 not only provides a designer surface for creating declarative workflows, but can also create apps for SharePoint and solutions that fully integrate Workflow Manager Client functionality.

Workflows in SharePoint 2013

Let’s start with some good news: the workflows that you have built for SharePoint 2010 will continue to work in SharePoint 2013. When you install SharePoint 2013, the SharePoint 2010 Workflow platform is installed automatically. But to make use of the new SharePoint 2013 Workflow platform you have to install and configure Windows Azure Workflow (WAW)separately from SharePoint 2013. Probably the easiest way to get it is using the Microsoft Web Platform Installer (Web PI at http://www.microsoft.com/web/downloads/platform.aspx) and searching in it for windows azure workflow. When the search results display, make sure you see the Workflow 1.0 and Workflow Client 1.0 versions. The Web PI then allows you to install both pieces of software, and starts a configuration wizard that you need to follow.

Note If you’re installing a development environment where SharePoint 2013 runs on a domain controller, you need to enter the Fully Qualified Domain Name of any end user names you’re using during the installation of WAW. So, instead of entering contoso\username, you need to enter contoso.com\username.

So, in a typical SharePoint 2013 farm, you will have two different Workflow platforms installed that you could use to create workflows. Other than SharePoint 2010 Workflows, and SharePoint 2013 Workflows, there is a 3^rd workflow platform option of the type SharePoint 2013 Workflow – Project Server. This type requires the presence of Project Server 2013 and falls outside the scope of this blog post.

You can choose to install the Windows Azure Workflow component on a separate server or farm of servers and connect it to your SharePoint farm. This allows you to scale the Workflow component according to your needs, and manage it separately. There are two different topology models for handling scale out scenarios: collocated and federated.

• In a collocated topology model, every SharePoint web front-end (WFE) is connected to its own dedicated Workflow Manager server, which is responsible for storing persistent data in a database that can be accessed by every Workflow Manager server. If there are multiple nodes in the SharePoint farm, traffic between SharePoint WFEs and Workflow Manager nodes takes place via HTTP and goes through SharePoint’s Network Load Balancer (NLB) or hardware NLB, if you’re using it.
• In a federated topology model, you can create a Workflow Manager farm, also known as a Workflow cluster, consisting of multiple Workflow Manager servers. A Workflow cluster can be reused by multiple SharePoint farms and can be managed completely independent of SharePoint. According to current best practices, workflow clusters should contain up to 3 Workflow Manager servers to ensure high availability. Based on Microsoft findings, this is more than enough to handle all kinds of high demanding workflow solutions.

Important Both topology models require the presence of the Workflow Manager client on every SharePoint node in the farm. See http://technet.microsoft.com/en-us/library/jj658588(v=office.15) for more information on how to do that. Workflow clusters can be created by specifying a farm scope in the Register-SPWorkflowService PowerShell cmdlet that will be discussed shortly hereafter.

Note This is a perfect example of the trend where pieces of custom software are encouraged to run outside of your SharePoint 2013 farm. This includes pieces of custom software such as workflows, InfoPath forms, SSRS reports, SharePoint Apps and so on. For administrators, this is great news as this is a huge step towards securing your SharePoint farm health.

After installing and configuring Windows Azure Workflow, you need to run the Register-SPWorkflowService PowerShell cmdlet to configure the communication between Windows Azure Workflow and SharePoint 2013. The easiest way to do this is to run this cmdlet within the SharePoint 2013 Management Shell and pass it at least the URL of the SharePoint site collection, the URI of the Windows Azure workflow host, and some optional arguments. For example:

Register-SPWorkflowService –SPSite “http://myserver/mysitecollection” –WorkflowHostUri “http://workflow.example.com:12291” –AllowOAuthHttp

Security Alert For production environments, OAuth expects the use of SSL so that all OAuth tokens are sent securely. Allowing OAuth over HTTP is a setting intended for use in development and test scenarios.

Port 12290 is used by default by the Windows Azure workflow host for HTTPS, while port 12291 is used by default for HTTP. If you’re not sure about the port number, you can always take a look at IIS Manager to find out which port you are using. The –AllowOAuthHttp flag must be added when you’re using HTTP instead of HTTPS, which ensures secure communication between your SharePoint 2013 site collection and the Windows Azure Workflow host.

Important You cannot connect Windows Azure Workflow to SharePoint Foundation. Installation of the features required for Windows Azure Workflow rely on files only found in SharePoint Server 2013 installations, specifically in the OSFSERVER install files. These files are not available in SharePoint Foundation, and therefore it is only possible to connect Windows Azure Workflow to SharePoint Server 2013.

See Also More information about connecting Workflow Managers on servers that are not a part of your SharePoint 2013 farm can be found at http://technet.microsoft.com/en-us/library/jj658588(v=office.15).

Workflow subscriptions and associations

As you have learned, the most significant change to SharePoint 2013 workflows is the moving of workflow processing onto an external workflow hosts (Windows Azure Workflow). Because of this, it was essential for SharePoint messages and events to connect to the workflow infrastructure in Windows Azure. In addition, it was necessary for Windows Azure to connect the infrastructure to customer data. Workflow associations (which are built on the WF concept of subscriptions) are the SharePoint infrastructure pieces that support these requirements.

Before we can discuss workflow associations and subscriptions, we must take a look at the Windows Azure publication/subscribe service, which is sometimes referred to as pub/sub, or simply PubSub. PubSub is an asynchronous messaging framework. Message senders (publishers) do not send messages directly to message receivers (subscribers). Instead, messages are rendered by publishers as classes which have no knowledge of the message subscribers. Subscribers, then, consume published messages by identifying messages of interest, regardless of the publisher, based on subscriptions that they have created.

This decoupling of message creation from message consumption allows for scalability and flexibility. It enables multicast messaging on the publisher side (where one message sent by a single publisher is received by multiple subscribers), and for promiscuous message consumption on the subscriber side (a subscriber receives messages by multiple publishers).

Note The PubSub feature is a part of the Windows Azure Service Bus, which provides connectivity options for WCF and other service endpoints. These include REST endpoints, which can be located behind network address translation (NAT) boundaries, or bound to frequently changing, dynamically assigned IP addresses, or both. For more information about the Windows Azure Service Bus, see http://msdn.microsoft.com/en-us/library/windowsazure/ee732537.aspx .

Workflow associations bind workflow definitions to a specific SharePoint scope, with specific default values. The associations themselves represent a set of subscription rules that are stored in the Windows Azure publication/subscription service that process incoming messages to ensure that they are consumed by appropriate (that is, subscribed) workflow instances. By default, the messaging infrastructure supports workflows at the following scopes:

• SPList (for list workflows)
• SPWeb (for site workflows)

Unlike previous versions, SharePoint 2013 does not support workflows that are scoped to a content type (SPContentType). However, the messaging infrastructure is extensible, so it can support any arbitrary scope.

Note Although outside of the scope of this blog post, it may be of interest to know that developers of custom workflows can set the EventSourceId property on a given WorkflowSubscription instance to any Global Unique Identifier (GUID). Workflow developers can then use that EventSourceId value to call the PublishEvent(Guid, String, IDictionary<(Of <<‘(String, Object>)>>)) method, which triggers a new workflow instance of the specified WorkflowSubscription. In other and simpler words, this allows custom solutions to notify SharePoint workflows of their own custom events.

Workflow Modeling and Development Tools

Typically, administrators won’t be responsible for creating custom workflows. Having said that, there are exceptions to this rule, and it’s certainly to be expected of SharePoint administrators that they have a working knowledge of existing workflow modeling and development tooling.

Important If you want to be able to understand the complete workflow architecture in SharePoint and its surrounding workflow tooling, it’s unavoidable to learn about the workflow modeling and development tools. A basic working knowledge of these tools will make you more effective in your job as a SharePoint administrator.

The following tools are available for creating custom workflows:

• Visio 2013 can be used to create a graphical design of a workflow. It is not possible to create a fully active workflow that can be published to SharePoint directly. What you can do is use Visio 2013 to transform business processes into SharePoint workflow artifacts and import such workflows into SharePoint Designer 2013, where it can be processed further and published to SharePoint. Business analysts are the primary audience for this tool.
• SharePoint Designer 2013 can be used to model new workflows or edit existing workflows in a graphical, non-programming, way. You can create fully active workflows using this tool. SharePoint power users are the primary audience for this tool.
• Visual Studio 2012 is used to create workflows that can be associated with any list or library. This is the most powerful tool for creating custom workflows, as it provides its users full access to the programmatic capabilities concerning SharePoint workflows. It must come as no surprise that Visual Studio 2012 is primarily aimed at developers.

Using Visio 2013, a business analyst or information worker can design a workflow. The building blocks of the workflow can be put into place but the values of those building blocks not. This effectively allows business analysts to design the logical structure of a business process and capture that workflow artifact in a form that can be taken for further processing. The actual configuration of SharePoint workflow artifacts can be further handled in SharePoint Designer 2013.

Visual Studio 2012 and SharePoint Designer 2013 both provide a fully declarative, no-code authoring environment for creating custom workflows. A declarative workflow is a workflow that is fully described in the XML language XAML without using any code, which, from a security standpoint, is a huge advantage. XAML is interpreted at run time by the workflow engine and is derived from the stages, steps, actions, and conditions, etc. that you have used to create a custom workflow in either SharePoint Designer 2013 or Visual Studio 2012. The building blocks that are available for creating XAML documents differ depending which tool you use.

Note All workflow modeling and development tools mentioned in this section are examples of Domain Specific Language (DSL) tools. A DSL is a programming language dedicated to a particular problem domain, using its own particular problem domain visualization techniques. The various SharePoint 2013 workflow tools offer a graphical language that allows you to create workflows without having to write a single line of XAML.

You have learned that Visio 2013 cannot be used to actually create workflows that can be published directly to SharePoint, and that you would actually need to use either SharePoint Designer 2013 or Visual Studio 2012 to do this. So, when should you use which tool? That is always the question and we will take a moment to delve a little deeper into the answer.

Since SharePoint Designer 2013 and Visual Studio 2012 are both suitable to create declarative workflows, we will take a look at the different kinds of persons that would be interested in creating workflows. SharePoint Designer 2013 is easy to use and allows for Rapid Application Development (RAD). Therefore, in that respect, SharePoint Designer 2013 is suitable for use by all interest groups: information workers, business analysts and SharePoint developers. On the other hand, SharePoint Designer 2013 is quite powerful and to be able to create a workflow using SharePoint Designer 2013 you have to be familiar with the core workflow components, like stages, actions, conditions and loops. Because of this: the general audience for SharePoint Designer 2013 is described as consisting of power users: users that have a considerable working knowledge of SharePoint. Generally, this means that business analysts will stick to using Visio 2013: they will have extensive knowledge about the specific problem domain, but typically won’t have much SharePoint knowledge (or the need to learn about SharePoint at the power user level).

The target audience of Visual Studio 2012 is quite limited: it consists of intermediate or advanced software developers as the tool allows you to do actual programming. These developers have to be familiar with both Visual Studio itself as well as SharePoint.

Having described the general audiences for both tools, let’s take a look at their specific advantages and disadvantages. The overview below discusses the most important workflow features, and then explains which of the available tools is most suitable for handling those features.

• Rapid workflow development Using either SharePoint Designer 2013 or Visual Studio 2012, you can create workflows very quickly. This is because the workflows are created in a declarative fashion and both tools contain building blocks to create such workflows in an easy and visual way. Having said that, SharePoint Designer 2013 has a definite edge when it comes to rapid workflow development.
• Enable reuse of workflows A workflow created with SharePoint Designer 2013 can only be used on the list or library for which it was developed. SharePoint Designer 2013 does provide reusable workflows which can be used more than once in the same site. However, using Visual Studio 2012 you can create a workflow that can be associated with any list or library on any site and also be reused. That is a big advantage, so here the advantage lies with Visual Studio 2012.
• Create a SharePoint workflow solution or workflow App for SharePoint Using SharePoint Designer 2013 it is absolutely not possible to create these. However, Visual Studio 2012 is created for these types of artifacts. Therefore, this tool has an absolute advantage over SharePoint Designer 2013.
• Create custom actions Using SharePoint Designer 2013, you cannot create custom actions, you can however use custom actions created and deployed with Visual Studio 2012. Visual Studio 2012 does allow you to create custom actions.
• Create custom code This is not possible using either SharePoint Designer 2013 or Visual Studio 2012. Even in Visual Studio 2012, you now only have a visual design surface to create workflows.

Note As stated repeatedly, Visual Studio 2012 does allow developers to create custom code in a form. They will have to do so in the form of creating custom actions or calls to separate WCF services, since it’s not possible anymore to add custom code to workflows directly.

• Make use of workflows created by Visio 2013 In SharePoint Designer you can import workflows made using Visio 2013, this is not possible with Visual Studio 2012.
• Deployment In SharePoint Designer 2013, deployment is done automatically once you’ve clicked the Publish button. Using Visual Studio 2012, you can create a SharePoint solution package and deploy your workflow to a site. With both tools you can package the workflows and deploy them to a remote server, although Visual Studio 2012 allows you more control over this process, whereas SharePoint Designer 2013 makes deployment just a little bit easier.
• Debugging It is not possible to debug custom workflows in SharePoint Designer 2013; with Visual Studio 2012 you can debug workflows. This is an essential capability for workflows that are more complex in nature.

Concluding, you have seen why Visio 2013 is the premier tool of choice for business analysts (it is great for capturing business processes but can’t be used to publish workflows to SharePoint), why SharePoint Designer 2013 is the premier tool of choice for power users (in general, it’s easier to use then Visual Studio 2012, and does allow you to publish workflows to SharePoint), and why Visual Studio 2012 is the premier tool of choice for developers (it’s the most powerful of all tools). In the next sections, you will take a closer look at each of the different SharePoint workflow development tools.

Visio 2013

In this section, you will take a closer look at the Visio 2013 tool. Visio 2013 makes it easy to create workflows if you’re used to working with Visio. As a result, this tool is specifically interesting for business analysts and process consultants who know exactly about the logical steps of a workflow/business process, but aren’t experienced (or SharePoint savvy) enough to implement it themselves using SharePoint Designer 2013 or Visual Studio 2012. These users will typically use Visio 2013 to create a mock-up workflow, and hand this workflow artifact over to either developers or power users that will use it as a starting point for the further implementation and configuration of the workflow.

After creating a workflow using Visio 2013, it can be exported to SharePoint Designer 2013. In SharePoint Designer 2013, after importing the Visio 2013 workflow, power users can add logic to the workflow steps by using the workflow text editor or/and the new Visual Workflow Designer. When they’re done, the power users can publish the workflow to SharePoint 2013.

Note SharePoint Designer 2013 contains a new Visual Workflow Designer which shows a visual representation of the workflow in the way the workflow is shown in Visio 2013. This is done via a Visio 2013 add-in in SharePoint designer 2013. This requires Visio 2013 to be installed on the same machine as SharePoint Designer 2013. Check for available licenses as Visio 2013 is a part of Office 2013 and is not free, as opposed to SharePoint Designer 2013.

Visio 2013 contains a new template called the SharePoint 2013 Workflow template. This template contains three stencils: Actions, Conditions, and Components, as shown in Figure 2.

Figure 2 Visio 2013 workflow stencils.

Using the shapes in these stencils you can build a workflow. That is very easy because the only thing to do is to drag the workflow shape onto the drawing canvas. It is only the visual that you’re dragging onto the canvas, since using Visio 2013 you cannot add the logic behind the visual. This can be added later using SharePoint Designer 2013. Figure 3 shows a sample Visio 2013 workflow diagram.

Figure 3 Example of a Visio 2013 workflow diagram.

Best Practices After modeling the workflow in Visio 2013, you can check if the workflow contains any errors by clicking the Check Diagram button in the ribbon. You should do this every time before exporting the Visio 2013 workflow diagram.

SharePoint Designer 2013

If you are knowledgeable about SharePoint and want to take it to new limits, or even want to develop SharePoint applications, there comes a time when you need to take a look at SharePoint Designer 2013, a tool that enables rapid SharePoint development. SharePoint Designer 2013 allows advanced users and developers to create no-code solutions for a variety of problems. This is especially true when it comes to creating custom workflows; traditionally this has been made quite easy via SharePoint Designer 2013.

New functionality in SharePoint Designer 2013

SharePoint Designer 2013 contains support for the new workflow platform specifically designed for Windows Azure Workflow. This platform is called the SharePoint 2013 Workflow Platform. The new functionality that can be found in SharePoint Designer 2013 to support this new platform includes:

• A new visual designer that makes use of a Visio 2013 add-in.
• A new action called Call HTTP Web Service with which you can make no-code web service calls from within a SharePoint Designer 2013 workflow.
• New actions for assigning a task and starting a task process. With both actions you can edit the Task Creation Email and the Task Overdue Email.

Real World These features are very popular and have been requested for a long time. Expect that these actions will be used a lot. I’m especially excited about the ease with which custom tasks can be made, and the amazing new opportunities to access external lists. Think, for example, of a customer list. Now think that just by entering customer names, a workflow kicks off and fills in the rest of the customer details in the list, such as phone numbers, addresses, and such. By the way, all web services responses are handled asynchronously by the Workflow Services Manager and managed using a throttling mechanism, so you don’t have to worry about blocking your workflow or workflow timer jobs. You can even poll a web service repeatedly by creating a stage that calls a web service, followed by another stage that pauses for, let’s say 1 hour, and then goes back to the first stage that calls the web service. That way, the information retrieved from a web service always stays up to date.

• New actions for starting a List workflow or a Site workflow that are built on the SharePoint 2010 platform.
• A new Dictionary type that can be used to store variables. When creating a workflow, most of the time the workflow creator will save a value in some variable (i.e. x = 10, or currentDate = 10/8/12) so you can use this value in other parts of the workflow. The Dictionary variable type is a container that is designed to hold a collection of different variables. So suppose you want to store the name and the birthday of an employee, you could use the Dictionary variable type to create an Employee Dictionary instead of creating two separate variables EmployeeName and EmployeeBirthday. In other words, dictionaries allow you to create logical groups that make it convenient to store related information together. The following new actions are designed specifically for working with the Dictionary variable type:
  • Build Dictionary With this action you can create a Dictionary variable type, create the various variables that are part of this dictionary, and give the Dictionary variable itself a unique and descriptive name.

Note You can nest Dictionary variables, in other words, you can put Dictionary variables into another Dictionary variable. This can be very beneficial, and helps to make your custom workflows clean, structured, and easy to understand. For example, you could have an Employees dictionary containing multiple Employee dictionaries. In other words, the Employees dictionary acts as a collection of Employee entities. Each employee dictionary could, in its turn, contain the name of the employee, address and job title. This way, SharePoint workflow development introduces some techniques commonly found in traditional object oriented (OO) programming.

• Count Items in a Dictionary Using this action, you can count the number of variables that a Dictionary contains and store that number in an Integer variable. This can be handy in case you would want to loop through all the items in a Dictionary, a very common task.
• Get an Item from a Dictionary This action can be used to retrieve the value of a specific variable from a Dictionary and store it in another variable.
• There are new workflow building blocks:
  • Stage Using the building block Stage you can group conditions and actions together. Before moving on to the next stage, all conditions and actions are processed in the order as listed within the stage. Again, this is an improvement that makes it easier to create workflows in a clean and structured way. Improvements such as these go a long way towards making complex workflows easier to build and manage.
  • Loop A loop contains a series of actions that is executed repeatedly for just as long as the specified conditions are true (i.e. while a task isn’t completed, send reminder e-mails).

Note Loops have been a much requested feature for SharePoint Designer. Probably the most anticipated one. In SharePoint 2010, workflow Loops where only available in Visual Studio 2010 as it was considered too dangerous to hand the power of Loops and its possible disastrous side-effects to power users. One misconstrued infinite loop in a custom workflow could have a definite impact on SharePoint farm performance. Now, since SharePoint 2013 workflows run outside the SharePoint farm, such risks are considered to be acceptable.

• App-Only Step The contents of this step will run as the workflow application.
• You can choose on which workflow platform you want to build a workflow, 2010 or 2013.
• Windows Azure Workflow capabilities

Figure 4 The Visio 2013 add-in available in SharePoint Designer 2013.

Because workflows are built using Windows Azure Workflow these workflows automatically gain several new capabilities like:

• High Density and Multi-Tenancy The multi-tenant hosting capabilities provide for safe, high efficiency and high performance execution of workflow instances.
• Elastic Scale Elastic scale refers to the fact that the workflow service is able to manage scaling up and down of the required system capacity whenever it is necessary. This is a typical trait of cloud solutions. This advantage applies to Office 365 only.
• Activity / Workflow Artifact Management There are also new capabilities for managing activities and workflows in the system. You can upload your activity via a REST API or client library, and the activities are stored in a scaled out, reliable repository. The relations between the activities, workflow definitions and the versions of the workflow definitions are also managed.
• Tracking and Monitoring There are several ways to monitor your workflow including:
  • Performance Counters Performance counters are grouped by counter sets. There are two counters sets available: Workflow Management and Workflow Dispatcher. Figure 5 shows the Performance Monitor. The available performance counters for workflows are:
    • Management requests per second
    • Workflow events per second
    • Management request failures per second
    • Authorization errors per second
    • Publish workflow event duration
    • Episodes outstanding
    • Episodes failed per second
    • Events processed per second

Figure 5 Relevant SharePoint 2013 workflow performance counters available via the PerfMon tool.

• Event Tracing Event Tracing for Windows (ETW) is used for tracing since this has the least overhead in terms of performance. The Event Tracing for Windows provider is called Microsoft-Workflow and the following channels are used: Operational, Debug, and Analytic. You can find a complete list of events generated by Windows Azure Workflow (version 1.0) at the following location: [InstallDrive]\Program Files\ Windows Azure Workflow\1.0\Workflow.
• PowerShell Using PowerShell you can easily administrate your workflow server. There are a couple of PowerShell cmdlets provided by Windows Azure Workflow that you can use to check the state of the workflow server and the health status. You must pay specific attention to two cmdlets: Get-WFFarm and Get-WFFarmStatus. The Get-WFFarm cmdlet provides a quick overview of details about your workflow farm, the hosts in your farm, and the endpoints on those hosts. The Get-WFFarmStatus cmdlet provides an overview of the basic status of the farm and the various nodes within the farm.
• System Center Operations Manager Management Pack This specific SCOM pack for Windows Azure Workflow allows you to leverage SCOM as an alerting mechanism that activates whenever a workflow failure is detected.
• Instance Management The hosting and management part of the workflow service and its instances are more advanced compared to SharePoint 2010.
• Fully Declarative Authoring This includes fully declarative authoring of workflows via an expanded activity library, expression translation and a new declarative data modeling feature.
• REST and Service Bus Messaging For REST and Service Bus Messaging, there are integrated messaging capabilities available. These messaging capabilities are integrated with the hosting runtime to ensure that inbound and outbound messages are coordinated with workflow persistence to guarantee the reliability and integrity of your processes.
• Managed Service Reliability All capabilities are provided as part of a managed service offering, which delivers the reliability and service availability that your business demands. This includes service health monitoring and management, performance and scale management, 24×365 operations support, fault tolerant design, cross-data center disaster recovery, service and platform upgrades and management, and standards compliance. This advantage applies to Office 365 only.
• Windows PowerShell cmdlets that manage workflow With the Get-SPDesignerSettings PowerShell cmdlet you can retrieve the SharePoint Designer 2013 settings that are enabled on a specific web application:

Get-SPDesignerSettings [-WebApplication] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>]

You can also set the SharePoint Designer 2013 features of a specific web application by using the Set-SPDesignerSettings cmdlet:

Set-SPDesignerSettings [-WebApplication] <SPWebApplicationPipeBind> [-AllowDesigner <$true | $false>] [-AllowMasterPageEditing <$true | $false>] [-AllowRevertFromTemplate <$true | $false>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ShowURLStructure <$true | $false>] [-WhatIf [<SwitchParameter>]]

Creating and Deploying Workflows in SharePoint Designer 2013

We will take a quick tour on how to create workflows in SharePoint Designer 2013 and show you how to deploy the workflows to SharePoint 2013. In this tour, you will also learn how to import a workflow created using Visio 2013 into SharePoint Designer 2013 and how to export a workflow created in SharePoint Designer 2013 to Visio 2013.

1. Open SharePoint Designer 2013 and open a SharePoint site.

2. You can either create a new workflow or edit an existing workflow. If you’re going to edit an out of the box existing workflow we advise you to make a copy of the original workflow. You can use one of the following options to create a new workflow or edit an existing one:

· On the New group of the Site tab of the Ribbon, you can create a new List Workflow, Reusable Workflow, or Site Workflow.

· By selecting the File tab of the Ribbon you will also have the choice to create a new List Workflow, Reusable Workflow, or Site Workflow.

· Select Workflows under Site Objects in the Navigation Pane. By selecting the New group of the Workflow tab of the Ribbon, you can create a new List Workflow, Reusable Workflow, or Site Workflow. Here you can also select an existing workflow and edit the workflow by selecting Edit Workflow on the Edit group of the Workflow tab. Or you just right click the workflow you want to edit and select Edit Workflow.

3. Open SharePoint Designer 2013 and open a SharePoint site.

4. Regardless which type of workflow you want to create, you always have to specify the Name and Description (optional) for the new workflow. For a new reusable workflow, you also have to select the content type you want to limit the workflow to. Other than that, you also have to make sure that you select the SharePoint 2013 Workflow platform type.

5. The next step is to create the workflow. SharePoint Designer 2013 contains a various set of Conditions and Actions you can add. You can also add Steps, Loops, and Parallel Blocks.

6. You can edit the settings for the workflow via the Manage group of the Workflow tab of the Ribbon. Here you can edit, for example, the workflow information, the settings of the workflow as well as other options.

For each task that you add to the workflow via a Task action, it is possible to set the task properties such as the description of the task, specify if you want to wait for task completion, and define various email options. Regarding these email options, you should know that you can specify the frequency of the email: daily, weekly, or monthly, how many times you want an overdue email to be sent and, last but not least, you can customize the Task Creation Email and the Task Overdue Email. See Figure 6 for a sample Task Creation Email edit window.

Note Customizing the tasks Task Creation Email and Task Overdue Email are certainly not the least interesting option. The ability to specify custom email messages is a popular request for almost every customer. In previous versions, this used to be more work, but in SharePoint 2013 this has become really easy.

7. After creating the workflow you can check if there are any errors. You can do this by selecting the Check for Errors menu item on the Save group of the Workflow tab.

8. If there are no errors in your workflow you can publish the workflow via the Save menu item on the Save group of the Workflow tab.

Figure 6 Creating a custom email message has become really easy.

Importing workflows from Visio 2013

It is possible to model a workflow using Visio 2013 by making use of visual building blocks, save the workflow and import this workflow into SharePoint Designer 2013. The following procedure shows you how to import a Visio 2013 workflow in SharePoint Designer 2013.

See Also See section “Visio 2013” for more information about creating Visio 2013 workflows.

1. Open SharePoint Designer 2013 and open a SharePoint site.

2. Select Workflows under Site Objects in the Navigation Pane.

3. Select Import from Visio from the Manage group of the Workflow tab of the Ribbon. This opens the Import Workflow From Visio dialog box.

4. Click Browse and select your Visio SharePoint workflow diagram and click Open.

5. Select the kind of workflow that you want to import and depending on what type of workflow you have selected you have to choose a list or a content type to associate the workflow to.

6. Click Finish.

At this point you have imported a Visio 2013 workflow in SharePoint Designer 2013 and you can edit this workflow. Then, you can start defining values for the actions and conditions that you’ve created with Visio 2013. Once you’re finished, you can publish this workflow to SharePoint 2013.

Note As a quick reminder: further configuration and workflow publication is something that can’t be done in Visio 2013 itself. This is a design choice by Microsoft: business analysts are supposed to be knowledgeable about business processes, not about SharePoint. Microsoft doesn’t want to force this audience to become SharePoint specialists before you are able to leverage their knowledge.

Exporting workflows to Visio 2013

Because SharePoint Designer 2013 contains a Visual Designer that is based upon Visio 2013, it is possible to export your workflow made in SharePoint Designer 2013 to Visio 2013 format. This is a great way to validate a workflow design and gather input from business analysts. The next procedure shows you how to export a SharePoint Designer 2013 workflow to Visio 2013 format.

1. Open SharePoint Designer 2013 and open a SharePoint site.

2. Select Workflows under Site Objects in the Navigation Pane.

3. Select Export to Visio from the Manage group of the Workflow tab of the Ribbon.

4. The Export Workflow to Visio Drawing dialog box opens, select a location where you want to save your Visio drawing, enter a name and click Save.

At this point, you’ve saved your SharePoint Designer 2013 workflow as a Visio drawing. You can now open Visio 2013 and select the workflow. You can edit the workflow and change the shapes, save the workflow or export it to work on it again in SharePoint Designer 2013.

Visual Studio 2012

Using Visual Studio 2012, you can create declarative workflows. Visual Studio 2012 contains a visual workflow designer surface to create workflows in a designer environment. For Visual Studio developers, the most significant change is that workflows are no longer compiled and deployed as .NET framework assemblies. Instead, Visual Studio 2010 creates XAML documents that are interpreted directly by the workflow engine.

Workflows are designed to run on WAW and work with Apps for SharePoint. For on-premises farms, the WAW servers also run on premises. For Office 365, WAW runs in the cloud (Azure). Running workflows on WAW enables you to remotely run and host workflows outside SharePoint Server. The workflows no longer make use of InfoPath forms, only ASP.NET forms are used. There is no distinction between state or sequential workflows anymore, as stages (discussed previously) can be used to create state workflows if needed.

Workflows now have their own identity, the App identity or App principal, which it gets as a result from the new SharePoint App model where workflows are now considered to be Apps, just like lists, libraries, events, and such. The reverse is also true: custom Apps can include custom logic as well as contain SharePoint workflows and leverage that as part of its custom logic. So, SharePoint 2013 workflows are Apps, not all Apps are SharePoint 2013 workflows, and some Apps contain SharePoint 2013 workflows. If workflows are part of another App, they run under the App identity of that App instead of having their own App identity.

The default access scope of a workflow is read/write permissions to the host site (which can be checked via Site Settings > Site App Permissions, then look at the Workflow App Display Name). If workflows run as part of another App, they run under the permissions granted to that App.

By default, when workflows access SharePoint resources, both the Workflow App identity and the end user have to have access in order for the action to succeed. Alternatively, workflows can be created that use so-called App Step actions (also available within SharePoint Designer), that are placed within Stages. Any action placed within an App Step succeeds if the Workflow App identity has sufficient permissions to complete the action, regardless of whether the end user has access or not. This is the SharePoint 2013 way of elevating end user privileges. App Steps are only available if the Workflows can use app permissions site feature is activated.

Note It’s a remarkable move that InfoPath forms are no longer used in workflows. InfoPath in combination with Forms Services is a great platform that makes it quite easy to create robust and nice looking web forms. I’ve found that one of the places where InfoPath really shines was within SharePoint workflows. InfoPath forms are rendered to HTML by Forms Services, running as a service within your SharePoint farm. To me, this is just another example of the clear trend where Microsoft tries to move custom code outside of your SharePoint environment.

If you want to create a workflow using Visual Studio 2012 you first have to create a SharePoint 2013 project, as shown in Figure 7.

Figure 7 Start developing a SharePoint workflow by creating a SharePoint 2013 solution within Visual Studio 2012.

After the creation of a SharePoint 2013 project you have to add a new workflow item to the project. When you have done this, the designer surface will open, as shown in Figure 8.

Figure 8 The workflow designer surface in Visual Studio 2012.

As stated earlier you can only write no-code workflows using Visual Studio 2012. If you want to write custom code for your 2013 workflow you’re supposed to create a custom WCF service and call that service from the new HTTP activities that are available, such as:

· HttpDelete An activity for sending an HTTP Delete request (a request to delete a server resource) and receiving an HTTP response.

· HttpGet An activity for sending an HTTP get request (a request for retrieving a server resource) and receiving an HTTP response.

· HttpMerge An activity for sending an HTTP merge request (a request for updating a server resource) and receiving an HTTP response.

· HttpPost An activity for sending an HTTP post request (a request for submitting information to the server) and receiving an HTTP response.

· HttpPut An activity for sending an HTTP put request (a request for creating a server resource if it doesn’t already exist, or update an existing server resource) and receiving an HTTP response.

Visual Studio 2012 also contains a workflow custom action-item type to create a custom activity. This custom activity can also be imported in SharePoint Designer 2013 (see Figure 9).

Figure 9 Creating a custom workflow activity.

Setting up and configuring SharePoint 2013 workflows

You can enable workflows in SharePoint 2013 without thinking about security and configurations, but that should be contrary to all of your administrator instincts. In the next sections, you will learn how to set up SharePoint workflow configuration.

Enable or disable user-defined workflows

As an administrator you’re able to decide if you want to allow users to deploy declarative workflows on a specific web application. By default, users can deploy declarative workflow to a SharePoint 2013 site. These are workflows that are created using SharePoint Designer 2013 or Visual Studio 2012. There are some scenarios where you don’t want users to deploy workflows without you, the administrator, knowing about it. The following procedure shows you how to enable or disable the deployment of declarative workflows.

1. Go to SharePoint 2013 Central Administration.

2. In the section Application Management, click Manage web applications.

3. Select the web application for which you want to change the user defined workflow settings.

4. Go to the Web Applications tab in the Manage section, click General Settings and select Workflow.

5. The Workflow Settings dialog box opens and contains the following settings (see Figure 10):

· Yes – enable user-defined workflows for all sites on this web application.

· No – disable user-defined workflows for all sites on this web application.

6. Click OK to close the Workflow Settings dialog box.

Figure 10 Inspect available workflow settings.

Configuring task notifications

SharePoint wouldn’t be as effective if end users would have to go and actively find out if there are any tasks waiting for them. Typically, end users will be notified when tasks are awaiting them. An interesting case and security issue arises when internal end users get task assignments within sites where they don’t actually have sufficient permissions, or when external end users get task assignments. As an administrator, there are several generic task notification settings surrounding these issues you can set per web application. The following procedure demonstrates how to specify these settings:

1. Open SharePoint 2013 Central Administration.

2. In the section Application Management, click Manage web applications.

3. Select the web application for which you want to configure the task notification settings.

4. Go to the Web Applications tab in the Manage section, click General Settings and select Workflow.

5. The Workflow Settings dialog box opens and contains the following settings:

· Yes – alert internal users who do not have site access when they are assigned a workflow task.

· No – do not alert internal users who do not have site access when they are assigned a workflow task

· Yes – allow external users to participate in workflow by sending them a copy of the document.

· No – do not allow external users to participate in workflow by sending them a copy of the document.

6. Click OK to close the Workflow Settings dialog box.

Configuring Workflow timer jobs

Timer jobs run by themselves according to a specific predefined schedule, or are started manually. When timer jobs are executed, they run in a specific Windows service, the SharePoint 2013 Timer service (SPTimerV4), on (depending on the timer job configuration) one or more SharePoint servers within your farm. A timer job contains a definition of the service to run and specifies how frequently the service is started. The following timer jobs are related to workflows: Workflow Auto Cleanup, Workflow, and Workflow Failover. Timer job schedules can also be specified via Windows PowerShell.

The following PowerShell cmdlets are available for timer jobs:

Disable-SPTimerJob The name speaks for itself, this cmdlet disables a timer job. The syntax is as follows (where Identity specifies the timer job to disable, this can be the GUID of the timer job, the name of the timer job, or an instance of a valid time job object):

Disable-SPTimerJob [-Identity] <SPTimerJobPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

· Enable-SPTimerJob This cmdlet enables a timer job. Before you can start a timer job you must enable it. The syntax is as follows:

Enable-SPTimerJob [-Identity] <SPTimerJobPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

· Get-SPTimerJob If you call this this cmdlet without specifying any parameters; it retrieves information about all timer job definitions within the SharePoint farm. By specifying the parameters, you can retrieve a specific timer job, timer jobs of a specific type, or timer jobs defined for a specified scope, for example SPWeb (SharePoint site scope). The syntax of this cmdlet is as follows:

Get-SPTimerJob [[-Identity] <SPTimerJobPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Type <String>] [-WebApplication <SPWebApplicationPipeBind>]

· Set-SPTimerJob This cmdlet can be used to set the schedule of a timer job. The syntax is as follows:

Set-SPTimerJob [-Identity] <SPTimerJobPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Schedule <String>] [-WhatIf [<SwitchParameter>]]

· Start-SPTimerJob This cmdlet runs a timer job once on each front-end Web server where the parent service is provisioned. The syntax is as follows:

Start-SPTimerJob [-Identity] <SPTimerJobPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Configuring Workflow Auto Cleanup timer jobs

When you associate a workflow to a SharePoint entity (such as a list), you have to choose or create a task list and a history list. Workflows that are completed and their related task entries are removed automatically after a default period of 60 days. This may be something you want to change, and you can do this by configuring the Workflow Auto Cleanup job, which is the timer job that is responsible for cleaning up the completed workflows and their task entries. Follow the next procedure to configure the Workflow Auto Cleanup job:

1. Open SharePoint 2013 Central Administration.

2. Select the Monitoring section on the left navigation bar.

3. In the Timer Jobs section, select Review job definitions.

4. On the Job Definitions page, select the Workflow Auto Cleanup job definition.

5. The Edit Timer Job shows the following options:

· The Job Title, in our case we’re looking for the Workflow Auto Cleanup timer job.

· The Job Description.

· The Job Properties, which contain the name of the web application as well as the last time the timer job ran.

· The Recurring Schedule section can be used to modify the schedule of the timer job. You can schedule the timer job to run every x minutes, or hourly where you can specify how many minutes past the hour the timer job can run, or daily where you can specify between which hours the timer job is allowed to run, or weekly where you can specify which day of the week the timer job can run, or monthly to be specified by the day of the month or the day of the month, for example the second Sunday of the month.

6. Finally, after configuring the schedule of the timer job, you have the following choices:

· Run Now, if you want the timer job to run immediately. This choice is great for testing purposes and administrators typically use it to run the timer job for the first time after initial installation.

· Disable, if you want to disable the timer job and don’t run it at all.

· Ok, if you’re satisfied with your new schedule and you want to timer job to run according to this schedule.

· Cancel, if you’re not satisfied and just want to keep your old or the default preferences.

Figure 11 Configuring Workflow timer job settings.

Configuring Workflow timer jobs

The timer job for cleaning up workflows and tasks, the Workflow Auto Cleanup timer job, is useful, but it’s not the only one you need to know. Next, we’re discussing the Workflow job. This timer job is responsible for processing queued workflow events that could not immediately be handled, and does this within the actual context of the web application. By default this timer job is scheduled to run every 5 minutes but this is adjustable, just follow the procedure as described in section “Configuring Workflow Auto Cleanup Timer Jobs”, only this time, look for the Workflow timer job.

Configuring Workflow Failover timer jobs

The last timer job to discuss is the Workflow Failover timer job. This timer job is responsible for processing workflow events that have failed and are marked to be retried. By default this timer job is scheduled to run every 15 minutes but this is adjustable, just follow the procedure as described in section “Configuring Workflow Auto Cleanup Timer Jobs”, only this time, look for the Workflow Failover timer job.

Deploying workflows

The following section shows you how to deploy a workflow in SharePoint 2013, arguably one of the top two tasks that fall under the responsibility of SharePoint administrators (the other one being workflow monitoring). The deployment method depends on the way the workflow was created, using either SharePoint Designer 2013 or Visual Studio 2012.

Although creating custom workflows is reasonably easy to do, don’t forget that there is a set of the out of the box workflows that is ready for use. No new workflows have been added in SharePoint 2013, so you can only choose from the list of workflows that was already available in SharePoint 2010. The following predefined workflows are available for use out of the box:

· Collect Feedback routes a document or item to a group of people for feedback.

· Approval routes a document or item to a group of people for approval.

· Disposition Approval, this workflow manages document expiration.

· Collect Signatures collects digital signatures from a group of people for a specific document created within an Office application.

· Three-State tracks the status of a list item through three different phases (such as Active, Resolved, and Closed).

· Translation Management manages manual workflow translation by creating and routing copies of source documents to designated translators for translation.

Note All of these out of the box workflows can be copied and customized to your specific needs. Although possible, it’s a best practice to refrain from adjusting the original workflows directly.

Deploying an out of the box SharePoint workflow

Out of the box workflows are workflows that are present by default on your SharePoint 2013 server. The out of the box workflow available in SharePoint 2013 are in fact the old SharePoint 2010 workflows, not 2013! We will nevertheless discuss how to deploy and use these workflows because they are also part of SharePoint 2013.

Important This is not a case where old SharePoint 2010 workflows are deprecated and are only there for backward compatibility reasons. On the contrary, the set of SharePoint 2010 workflows have been tested and used thoroughly over the years and there was no urgent reason to recreate them using the SharePoint 2013 workflow platform. Expect that this set of SharePoint 2010 workflows remains popular and useful and don’t hesitate to use them.

Before you can deploy and use the workflow you have to activate the corresponding features, otherwise these workflows won’t be visible. The following procedure shows you how to deploy a default workflow (later on, in section “Activating Workflows” we will discuss specifics for the most important default workflows):

1. Activate the workflow feature that corresponds to the workflow you want to deploy.

2. Associate the workflow you want to deploy to a list, library, content type, or site.

3. Start the workflow and check if it works!

Deploying a SharePoint Designer 2013 workflow

Deploying a workflow created with SharePoint Designer 2013 is very easy to do. The following procedure shows a high level overview of the steps you need to take to deploy a workflow that is associated with a list, library, content type, or site.

1. Create a workflow using SharePoint Designer 2013.

2. Check if the workflow contains any errors.

3. Deploy the workflow via the Publish button.

Deploying a Visual Studio 2012 workflow

Visual Studio 2012 workflows are packaged and deployed as features. The deployment of a feature includes installing a solution, activating a feature and associating the workflow to a SharePoint entity such as a list. The following procedure shows how to deploy a workflow created in Visual Studio 2012.

1. Create a workflow using Visual Studio 2012.

2. Package the workflow as a feature. This feature will be packaged as a solution file.

3. Install the solution on the SharePoint server.

4. Deploy the solution on the SharePoint server.

5. Go to the site collection and activate the workflow feature.

6. Go to the list, library, content type, or site and associate the workflow.

Activating workflows

Before using any type of workflow, whether it is an out of the box workflow or it is a workflow created with SharePoint Designer 2013 or Visual Studio 2012, you must activate the workflow before you can start associating the workflow. Table 1 shows which feature to activate for the most important out of the box SharePoint 2010 workflows that are available to you.

Table 1 Features and workflows

Feature	SharePoint 2010 out of the box Workflow
Disposition Approval Workflow site collection feature	Disposition Approval Workflow
Publishing Approval Workflow site collection feature	Publishing Approval Workflow
Three-state Workflow site collection feature	Three-state Workflow

Activating a feature

The following procedure shows you how to activate a feature:

1. On the top level of the site collection, click the Settings icon, and select Site Settings. This icon is located on the top right of the page.

2. In the Site Collection Administration section, click Site collection features.

3. On the site collection features page, activate the features that you need. Figure 12 shows a part of the site collection features page.

Figure 12 Activating features required for out of the box workflows.

Associating a workflow

After creating and deploying a workflow you have to associate the workflow. You have to do this for the out of the box, SharePoint Designer 2013, and Visual Studio 2012 workflows. Associating a workflow is more than adding the workflow to a list, library, content type, or site; it is also assigning a task list and history list to the workflow. You can select an existing task list or history list to use or you can create a new list. For a small site you could use just one task list or history list. But we recommend using a different task list and history list for each workflow, this way you avoid potential performance problems and it’s clear for the administrators and users. In the next sections we’re going to discuss how to associate a workflow to a list, library, content type, or site.

Associating to a content type

The following procedure shows you how to associate a workflow to a content type:

1. Go to the site where you want to associate a workflow to a content type.

2. Click the Settings icon which is located on the top right of the page, and select Site Settings.

3. On the Site Settings page in the Web Designer Galleries section, click Site content types.

4. On the Site Content Types page, select the content type that you want to associate with a workflow.

5. On the Site Content Type page of the content type you’ve selected in the Settings section, click Workflow settings.

6. On the Workflow Settings page, click Add a workflow. You can also use this page to view and change the workflow settings and to add or remove workflows.

7. On the Add a workflow page, select a workflow you want to associate to the content type.

8. In the Name section, type a unique name for the workflow that is recognizable and descriptive.

9. In the Task List section, enter the name of the task list you want to use or create. If you enter a name of an existing task list then that task list will be used. If you enter a task list name that doesn’t exists yet, then a new task list will be created.

10. In the History List section, enter the name of the history list you want to use or create. For the history list name the same things apply that apply to the task list name: if a history list with the same name already exists, that list will be used. Otherwise, a new history list will be created.

11. In the Start Options section, you can specify how the workflow can be started (see Figure 13). The following options are available to choose from:

· Allow this workflow to be manually started by an authenticated user with Edit Item permissions. Select this option to allow users to start the workflow manually. You also have an extra option called Require Manage List Permissions to start the workflow. This way you can make sure that only administrators can start the workflow.

· Start this workflow when a new item is created. Select this option when you want the workflow to start when a new item or document is created.

· Start this workflow when an item is changed. Select this option when you want the workflow to start when an existing item or document is updated.

12. In the Update List and Site Content Types section, you can choose if you want the workflow to be applied to all child content types.

13. Click Next to go to the next page. This second page contains additional configuration information specific for each workflow. When you’re done configuring the second page, click Save.

14. Now you can use the associated workflow with any item or document that inherits from the content type you’ve associated the workflow with.

Figure 13 Associate a workflow to a SharePoint entity.

Associating to a list or library

Use the following procedure to associate a workflow to a list or library:

1. Go to the site where you want to associate a workflow to a list or library.

2. If you want to associate a workflow to a list follow these steps:

a. Go to the list you want to use.

b. Select the List tab.

c. In the Settings section, select Workflow Settings and click Add a Workflow.

3. If you want to associate a workflow to a library follow these steps:

a. Go to the library you want to use.

b. Select the Library tab.

c. In the Settings section, select Workflow Settings and click Add a Workflow.

4. On the Add a workflow page select the workflow you want to add.

5. In the Name section, type a descriptive name for the workflow.

6. In the Task List section, provide a name for the task list you want to use. This can be an existing task list or a new one. If the task list doesn’t exist yet, a new one will be created automatically.

7. In the History List section, type a name for the history list. If the history list doesn’t exist yet, a new history list will be created automatically.

8. In the Start Options section you can specify how the workflow can be started. The following options are available to choose from:

· Allow this workflow to be manually started by an authenticated user with Edit Item permissions. Select this option to allow users to start the workflow manually. You also have an extra option called Require Manage List Permissions to start the workflow. This way you can make sure that only administrators can start the workflow.

· Start this workflow to approve publishing a major version of an item. This option is only available in document libraries when you have enabled content approval and are using major/minor versioning. This option is also only available for the Approval and Publishing Approval workflow.

· Start this workflow when a new item is created. Select this option when you want the workflow to start when a new item or document is created.

· Start this workflow when an item is changed. Select this option when you want the workflow to start when an existing item or document is updated.

9. Click Next to go to the next page. In this procedure, we have chosen the Disposition Approval workflow, in which case you just have to click the OK button.

10. This second page contains additional configuration information specific for each type of workflow. For example, when you choose to create an instance of the Collect Feedback workflow, you have to specify the names of the reviewers, and the content of a task request.

11. When you’re done configuring the second page, click Save.

Associating to a site

The following procedure shows you how to associate a workflow to a site:

1. Go to the site that you want to use to associate a workflow to.

2. Click the Settings icon and select Site Settings.

3. On the Site Settings page in the Site Administration Settings section, click Workflow settings.

4. On the Workflow Settings page, select the workflow you want to associate.

5. In the Name section, type a descriptive name for the workflow.

6. In the Task List section, select a task list you want to use or select the option New task list from the dropdown list.

7. In the History List section, from the dropdown list select a history list you want to use or select the option New history list.

8. In the Start Options section you can specify if you want the workflow to be manually started by an authenticated user with Edit Item permissions. In effect, this means users that are administrators. With site workflows, there are not many options available for starting workflows: you can only start a workflow manually.

9. After finishing the configuring options you can click the OK button.

Monitoring workflows

It is essential to monitor a workflow during the life cycle of the workflow. Arguably, this is the most important task you are responsible for when it comes to administrating workflows. You can do this via the associated list or library of a workflow scoped at that level. Alternatively, you can check the workflow status for site workflows. You can also check the workflow reports and troubleshoot errors that happen during the execution of the workflow. In the next sections, we will show you the various aspects concerning workflow monitoring.

Checking Workflow Status

First, you will learn how to check the status of a list or library workflow. This is done via the workflow status column. A new workflow feature in SharePoint 2013 is that workflow status columns are now treated as normal list columns, which means you can have access to all list column features and you can do all sort of things to these columns, such as ordering and filtering. The following procedure shows how to check the status of a workflow:

1. Go to the list where you’ve associated and started the workflow.

2. Every item in the list or library that contains a workflow has a workflow status column. This column contains the status of a workflow, for example In Progress. Click on the status of the workflow.

3. On the Workflow Status page, you will find a lot of workflow information as can be seen in Figure 14 which shows a part of this page.

4. On the Workflow Status page you will find the following workflow information:

· The name of the initiator of the workflow.

· The start date of the workflow.

· The date when the workflow last run.

· The name of the document or list item.

· The status of the workflow.

· A workflow visualization displayed in a Visio 2013 diagram (this is a new feature in SharePoint 2013 and is a great way to get an idea of what a workflow does). If you don’t want to interact with this visualization within a web interface, you can open the workflow visualization directly in Visio 2013, by clicking on the available Open in Visio link. This last option also allows you to make changes to the workflow. You can also find information about the shapes that are used in the workflow by clicking on the Shape Info link.

· Links to tasks associated with the workflow, for example approval workflows will display a link that cancels all approval tasks.

· A link to terminate the workflow immediately. This can sometimes be useful if a workflow contains errors or stops responding. The workflow status will be set to Canceled and all workflow tasks will be deleted.

· An overview of all the tasks that are assigned together with their status. You can also click on the task and have a look at the contents.

· An overview of the workflow history. The events logged into the history list contain the Date Occurred, the Event Type, for example an error, User ID, and Description

Figure 14 Monitoring running workflows.

The following procedure shows you how to check the workflow status of a site workflow:

1. Go to the site that you want to check.

2. Click the Settings icon, and select Site Settings.

3. On the Site Settings page in the Site Administration section, select Workflow Settings.

4. To view the status of a workflow, just click on the name of the workflow.

5. The Workflow Settings page shows the following information:

· The name of the initiator of the workflow.

· The start date of the workflow.

· The date when the workflow has run for the last time.

· The status of the workflow.

· An overview of all the tasks that are assigned together with their status. You can also click on the task and have a look at the contents.

· An overview of the workflow history. The events logged into the history list contain the Date Occurred, the Event Type, for example an error, User ID, and Description

Troubleshooting workflow issues

Because SharePoint 2013 uses a new workflow platform, namely Windows Azure Workflow, and because Visual Studio now creates declarative workflows, developers cannot put code directly into custom workflows anymore. The only way to add custom code to workflows is to either create a custom activity that can be used within a custom workflow, or put the custom code into a web service and call the web service from one of the new workflow HTTP activities. This makes debugging a lot harder.

Troubleshooting Out of the box workflows

Let’s start the discussion of troubleshooting workflows by taking a look at the out of the box workflows. The first hint that an out of the box workflow contains an error is that the SharePoint item workflow status in the UI displays the Error workflow status. The best thing to do when this happens is to take a look at the history list of that workflow and figure out where the workflow went wrong. The most common errors are connectivity problems, incorrect email settings, or user permissions that are not correct, probably insufficient permissions.

Note A nifty way of making out of the box workflows easier to debug is to use SharePoint Designer to create a copy of one of the existing workflows and start adding logging capabilities to it. While this will definitely make it easier to debug out of the box workflows, this is usually overkill since the existing workflows have been tested thoroughly and have been around for a long time. So, not many, if any, inherent problems in the workflows exist. Plus, there’s a lot of support out there when it comes to using the default SharePoint workflows, for example in the form of the online SharePoint forums. Nevertheless, it’s good to know the option exists.

Troubleshooting SharePoint Designer 2013 workflows

There are no debugging options available in SharePoint Designer 2013. You cannot put breaks and step into the workflow while it’s running and take a look at the stack trace (which displays the code execution path so that it’s easier to determine where the workflow went wrong).

Note This style of troubleshooting is only suitable for development, and optionally test and staging environments. Debugging production environments using breaks etc. is extremely harmful for server performance and availability.

The only thing you can and should do is put comments at strategic places and take a good look at where the workflow fails. Such comments ultimately show up in the History lists associated to workflow instances and they form an essential aid when it comes to debugging workflows.

Important As an administrator, you should demand that as a part of the deliverables for a custom workflow, documentation is included detailing what kind of diagnostics instrumentation is included in the workflow, what kind of messages you should look for, and finally, you should ask about the meaning of those messages.

In addition, if you want to debug SharePoint Designer workflows at a lower level, you could take a look at the section “Debugging Workflows” to learn how to use Fiddler to closely watch all HTTP traffic that the workflow generates.

Troubleshooting Visual Studio 2012 workflows

Developers can easily debug Visual Studio 2012 workflows (again: not in a production environment); they can set breakpoints and run the workflow to watch where exactly and at which activity things go wrong. Administrators however, cannot do that, and shouldn’t want to do that. They have to look at either the log files or history list. So the best thing to do is to ask the developers to include detailed diagnostics instrumentation in their custom workflows, and make them provide clear documentation about it.

On a lower level, asking developers to include diagnostics is usually equivalent to asking them to use the WriteToHistory workflow activity in each workflow they create to make history log entries to track the status of the workflow and track where it failed. Make it a protocol that whenever a workflow is created, all important information and status of the workflow is logged using the WriteToHistory activity.

Important Logging guidelines should be a part of the deployment guidelines of your company. You should not allow the deployment of custom workflows without having such guidelines in place, and without making sure the custom workflows adhere to these workflows. Best practices concerning SharePoint 2013 have yet to emerge, but the TechNet Wiki SharePoint 2013 Best Practices page at http://social.technet.microsoft.com/wiki/contents/articles/12438.sharepoint-2013-best-practices.aspx is a good place to keep track of such emerging best practices.

Debugging workflows

The introduction of Windows Azure Workflow in SharePoint means that workflows are hosted and executed within an environment external to SharePoint. This also means that behind the scenes, a lot of communication at the HTTP level is going on between SharePoint and Windows Azure Workflow. As a result, a lot of information can be obtained by monitoring HTTP traffic between your SharePoint farm and Windows Azure Workflow. And that’s not all, as you have learned; WCF services have become increasingly important as a means to add custom code to custom workflows. This means yet more HTTP traffic.

In this section, you will learn how to debug SharePoint 2013 workflows using an HTTP traffic monitoring tool such as Fiddler. Or, to take a quote from the Fiddler web site: Fiddler is a free web debugging proxy that can be used to log all traffic the computer and internet, you can download Fiddler here: http://www.fiddler2.com/fiddler2/. Fiddler is created by a Microsoft employee and has involved to the de facto standard when it comes to free HTTP traffic monitoring tools used in troubleshooting SharePoint deployments.

Important As opposed to the other techniques described in the “Troubleshooting workflow issues” section, this technique can be used in black box troubleshooting scenarios. In other words, if you can’t modify a workflow (or have it modified by somebody else) to add diagnostic info, and the current diagnostic capabilities of a workflow are not sufficient, you can still use this technique to find out more about the workings of a workflow and the problems it encounters. Although this technique can potentially be used in production environments, this should be done with extreme caution and off hours, as it will affect SharePoint server performance.

To use Fiddler to debug SharePoint 2013 workflows, just follow the next procedure:

1. Open Windows Explorer and go to the following location: %systemdrive%\Windows\Microsoft.NET\Framework\v4.0.30319\Config. Find the machine.config, make a copy of the file and open the original machine.config. The copy is just for backup in case something goes wrong. Add the following code to the end of the machine.config, just before the last closing tag.

<system.net>
<defaultProxy enabled=”true”>
<proxy bypassonlocal=”false” usesystemdefault=”true” />
</defaultProxy>
</system.net>

2. Save the file and close it.

3. Go to the next location using the Windows Explorer: %systemdrive%\Windows\Microsoft.NET\Framework64\v4.0.30319\Config. Find the machine.config, make a copy of the file and open the original file. The copy is just for backup in case something goes wrong. Add the following code to the end of the machine.config, just before the last closing tag.

<system.net>
<defaultProxy enabled=”true”>
<proxy bypassonlocal=”false” usesystemdefault=”true” />
</defaultProxy>
</system.net>

4. Save the file and close it.

5. Start Fiddler.

6. Intercept the HTTP traffic that is coming from SharePoint and Windows Azure Workflow by selecting Tools in the tool bar of the Fiddler product and clicking Fiddler Options. The Fiddler Options dialog box opens.

7. Click the Connections tab, as shown in Figure 15.

8. Select the following options:

· Reuse client connections

· Reuse connections to servers

· Act as system proxy on startup

· Monitor all connections

9. Click OK.

Figure 15 Monitoring HTTP traffic using the free Fiddler tool.

Now you must install the Fiddler certificate as a trusted root on the SharePoint server. This certificate is used to re-encrypt the traffic after debugging it.

1. Select Tools in the tool bar of the Fiddler product, and click Fiddler Options. The Fiddler Options dialog box opens.

2. Click the HTTPS tab.

3. Select the following options (which is necessary as SharePoint 2013 and Windows Azure Workflow communicate over SSL):

· Capture HTTPS CONNECTs

· Decrypt HTTPS Traffic

4. A windows box opens with the message that Fiddler generates a unique root certificate. Click Yes if you don’t mind reconfiguring a Windows Trusted CA list.

5. The next security warning pops up, now stating that you’re about to install a certificate with an unconfirmed thumbprint asking if you really, really want to do that. Click Yes.

6. Check the Ignore server certificate errors check box, as shown in Figure 16.

7. Click the Export Root Certificate to Desktop button.

8. You will see a popup window that says that the file FiddlerRoot.cer has been exported to your desktop. Click OK.

9. Click OK in the Fiddler Options dialog box.

Figure 16 Specifying advanced Fiddler options to inspect SharePoint-WAW traffic.

Now you must install the Fiddler certificate that is located on our desktop. You can do this using PowerShell.

1. Open the SharePoint 2013 Management Shell.

2. Copy or type the following in the SharePoint 2013 Management Shell:

certUtil.exe -addstore -enterprise -f -v root [path]\FiddlerRoot.cer
$trustCert = Get-PfxCertificate [path]\FiddlerRoot.cer
New-SPTrustedRootAuthority -Name “Fiddler” -Certificate $trustCert
IISRESET

Now that everything is configured, you’ve ended up editing two machine.config files, configured the interceptions of the traffic coming from SharePoint and Windows Azure Workflow, and finally you’ve installed the Fiddler certificate as a trusted root. In the final procedure, you will see what happens when everything is working:

1. Log in as the service account user for SharePoint and Windows Azure Workflow.

2. Open Fiddler.

3. Run iisreset to restart SharePoint. This way Fiddler is able to catch the traffic between SharePoint and Windows Azure Workflow.

4. Restart the Windows Azure Workflow by clicking Start, selecting Administrative Tool, and clicking Services. Go to the Workflow Service Backend service.

5. Right-click the Workflow Service Backend service and select Restart. This way Fiddler can monitor HTTP(S) traffic between SharePoint and Windows Azure Workflow.

Now that Fiddler is running, and SharePoint and Windows Azure are restarted, you will be able to inspect the communication between SharePoint and Windows Azure Workflow.

See Also To give credit where credit is due, as far as I know Andrew Connell was the first one to use and document this type of advanced workflow debugging. More information about this technique can be found at http://www.andrewconnell.com/blog/archive/2012/07/18/sharepoint-2013-workflow-advanced-workflow-debugging-with-fiddler.aspx.