Reference Implementation: Workflow Activities

In SharePoint 2010, site users can create powerful workflows in SharePoint Designer by connecting and configuring workflow actions. These workflows are known as declarative workflows, because the logic that connects the individual workflow actions is defined entirely in declarative markup and does not require custom code.

SharePoint 2010 includes many built-in workflow actions for common tasks and activities. As a developer, you can also make additional actions available to workflow creators in two ways:

  • You can create a full-trust workflow activity class and deploy it as a farm solution. To use these activities in SharePoint Designer, you must create and deploy a workflow actions file to package your activity, and you must add an authorized type entry for your activity class to the Web.config file.
  • You can create a sandboxed workflow action class and deploy it as a sandboxed solution. To be able to package your workflow action, you must create a feature with a workflow actions element in an element manifest file.

Both approaches make additional workflow actions available to users in SharePoint Designer. The full-trust approach allows developers to expose specialized functionality to workflow creators, such as connecting to external systems and services or performing actions across site collection boundaries. The sandboxed approach allows developers to introduce custom workflow logic to site collections in hosted environments or in other environments in which the deployment of farm solutions is prohibited. Sandboxed workflow action logic must observe the constraints of the sandbox environment—for example, sandboxed workflow actions cannot access external systems or services and are limited to a subset of the SharePoint API.


We recommend that you review Execution Models in SharePoint 2010 prior to studying the Workflow Activities Reference Implementation (Workflow Activities RI). It provides a more detailed explanation of many of the concepts described in this topic.

This implementation highlights details and best practices in the following areas:

  • Creating and deploying full-trust workflow activities
  • Creating and deploying sandboxed workflow actions
  • Consuming custom activities and sandboxed actions from a declarative workflow.

Solution Scenario

In this example, suppose you are a SharePoint consultant working for a pharmaceutical company named Contoso Inc. You have already designed and implemented a system that tracks the progress of statements of work (SOWs) and budget estimations, as described in Sandbox Reference Implementation. As a result, each team site on the Contoso intranet portal includes an Estimates list that contains SOWs and budget estimations. The Estimates list includes a field that indicates the approval status of each work item.

The IT manager at Contoso, Cristian Petculescu now wants you to extend this solution. Cristian wants you to automate the creation of project sites, so that when the approval status of a work item is set to Approved, a new project site is created and configured for that work item. To meet Gerhard's requirements, you first create various workflow activities:

  • You create a full-trust workflow activity to create a new site.
  • You create a full-trust workflow activity to determine whether the new site already exists.
  • You create a sandboxed workflow action to copy a document library from one site to another.


You could actually use a sandboxed workflow action to create a site, because this process takes place within the boundaries of the site collection. However, in the Workflow Activities RI, the CreateSiteCollection and CreateSite derive from a common base class, and you cannot create a site collection within a sandboxed workflow action.

Next, you use SharePoint Designer to create a declarative workflow that incorporates these activities. This workflow runs on each item in the Estimates list. When the approval status of the item is set to Approved, the workflow attempts to create a new project site for the work item. It then uses the sandboxed workflow action to copy the Templates document library to the new project site.

Deploying the Workflow Activities RI

The Workflow Activities RI includes an automated installation script that creates various site collections, deploys the reference implementation components, and adds sample data. After running the installation script, browse to the new ManufacturingWF site collection at http://<Hostname>/sites/ManufacturingWF. You can open and run the project in Visual Studio, but this does not create a site collection or add sample data. To see the system fully functioning, you must run the installation script. The following table summarizes how to get started with the Workflow Activities RI.



Where can I find the Workflow Activities RI?

<install location>\Source\ExecutionModel\Workflow

What is the name of the solution file?


What are the system requirements?

SharePoint Server 2010 Server Standard or Enterprise

What preconditions are required for installation?

  • You must be a member of SharePoint Farm Admin.
  • You must be a member of the Windows admin group.
  • SharePoint must be installed at http://<Hostname:80>. If you want to install to a different location, you can edit these settings in the Settings.xml file located in the Setup directory for the solution.
  • SharePoint 2010 Administration service must be running. By default, this service is set to a manual start. To start the service, click Start on the taskbar, point to Administrative Tools, click Services, double-click SharePoint 2010 Administration service, and then click Start.

How do I Install the Workflow Activities RI?

Follow the instructions in the readme file located in the project folder.

What is the default installation location?


(This location can be altered by changing the Settings.xml file in the Setup directory.)

How do I download the Workflow Activities RI?

The Workflow Activities RI is included in the download Developing Applications for SharePoint 2010.