Migrate In-Process Workflows from MOSS 2007 to SPS 2010 (Part 2 of 2)

Part 1 of this Article is Located - Here

Okay, now that we have a deeper understanding of the workflow process, and we have inspected our MOSS 2007 workflows to ensure they are ready to migrate, we are now ready to start the step-by-step methodology to migrate our in-process workflow:

(Two quick notes, the steps that follow are not all the steps involved in a SharePoint migration, and these steps assume the use of the Database Attach Upgrade Method).

Steps on the MOSS 2007 Server:

1. Run: stsadm -o preUpgradeCheck, Correct any Errors

2. Stop All Workflow Auto Cleanup Timer Jobs

• Central Administration > Operations > Timer Job Definitions > Edit Timer Job > Workflow Auto Cleanup - Disable

3. Quiesce the Farm

• Central Administration > Operations > Quiesce Farm - Start Quiescing - 5 minutes (more for production)
• Allow Quiesce to complete

4. Provide Sufficient Time for In-Memory/In-Process Workflows to Dehydrate (Usually No More Than 2 Hours)

5. Set the Content Database to Read Only

• SQL Server Management Studio > Databases > WSS_Content_MyCDB > Properties > Options > State > Database Read Only > True

6. Run PowerShell Command

• Start > All Programs >Accessories > Windows PowerShell > Windows PowerShell ISE
• Test-SPContentDatabase -Name WSS_Content_cdbTestIPWF -WebApplication http://shrpnt2007:8000/

7. Backup the Database

• SQL Server Management Studio > Management > Backup > Accept Defaults > OK
• C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\ 

Steps on the SPS 2010 Server:

1. Copy Workflow Solution Package to the SPS 2010 Server

• C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN

2. Deploy Custom Workflow WSP to Solution Management Store

• stsadm -o addsolution -filename
• stsadm -o deploysolution -name -immediate -allowGacDeployment

3. Copy Restore Database to...

• C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup

4. Stop All Workflow Auto Cleanup Timer Jobs

• Central Administration > Monitoring > Timer Jobs > Job Definitions > Workflow Auto Cleanup for > Disable

5. Remove CDB Database from

• Central Administration > Application Management > Databases > Manage Content Databases > > Remove Content Database > OK

6. Reset IIS - IISReset

7. Set the Content Database to Read Only

• SQL Server Management Studio > Databases > WSS_Content_MyCDB > Properties > Options > State > Database Read Only > True

8. Restore Database to SQL Server

• SQl Server Management Studio > Databases > Restore Database >
• General
• To Database (SPS 2010 CDB)
• From Device (MOSS 2007 Backup Copy)
• Check Restore
• Options
• Overwrite the Existing Database

9. Set Read Only Back to False

• SQL Server Management Studio > Databases > WSS_Content_MyCDB > Properties > Options > State > Database Read Only > False

10. Mount/Migrate the Database

• stsadm -o addcontentdb -url http://sp2010srv:8000 -databasename WSS_Content_cdbTestIPWF

11. Attach the Database to the Web Application

• CA > Application Management > Databases > Manage Content Databases > Add a Content Database > Database Name

12. Restart All Workflow Auto Cleanup Timer Jobs

• Central Administration > Monitoring > Timer Jobs > Job Definitions > Workflow Auto Cleanup for > Enable

Go to the SPS 2010 Sites, Lists and Libraries and test your migrated in-process workflows!


I hope that helps!

Tom

Migrate In-Process Workflows from MOSS 2007 to SPS 2010 (Part 1 of 2)

Part 2 of this Article is Located - Here

Recently I had the opportunity to develop a methodology for migrating in-process SharePoint workflows from MOSS 2007 to SPS 2010.  As you may be aware, in-process workflows are those workflows which have been started but which are not yet completed.  In this two part article I will provide a step-by-step methodology for migrating in-process workflows and thereby avoiding the gotcha's that are out there waiting for you. 

Understanding In-Process Workflow Migration

Before I dive into my methodology I wanted to provide a little background understanding of workflow processing:

Starting: Workflows can be Started in a Number of Different Ways

• Manually
• When an Item is Created
• When an Item is Changed
• Programmatically Through the API
• Programmatically Through the Web Service

 Hosting: Workflows can be Hosted by a Number of Different Processes

• W3wp.exe – When Started from the SharePoint Interface
• Owstimer.exe – When the Workflow is Delayed
• The Programmatic Process that Executes the Workflow Code

Delayed: When the Workflow Action needs to be Delayed the Workflow Dehydration Process Occurs

• The Windows Workflow Foundation Calls the SQL Workflow Persistence Service
• The SQL Workflow Persistence Service
• Assigns Correlation Token to Task
• Serializes Workflow Object – Turns Into Binary String
• Saves with a Unique ID in the Content Database

Reactivated: When the Workflow Action Needs to be Carried Out the Workflow Rehydration Process Occurs

• The Windows Workflow Foundation Calls the SQL Workflow Persistence Service
• The SQL Workflow Persistence Service
• Finds the Workflow task Using the Unique ID
• Deserializes Workflow Object – Turns Binary String Back Into an Object in Memory
• Performs Many Checks to Ensure the Right Workflow Object is Returned

 In-Process and In-Memory Workflows: Workflows can be In-Process and In-Memory (Not Dehydrated)

• Any Workflows that are In-Process and In-Memory will be Lost in Migration
• Custom Workflow Code can Prevent Workflows from Dehydrating – Therefore They Persist in Memory

DelayActivity – UnloadOnIdle: In-Process Workflows can be persisted in memory programmatically

• If Custom Workflow Code Uses a Delay Activity and UnloadOnIdle Property is Set to False the Workflow Object will Persist in Memory
• Custom Code Must be Reviewed and if Necessary Modified to Prevent UnloadOnIdle from Persisting Workflow Objects – Set Property to True

External Applications: If External Application Activate Workflows Within SharePoint then Those Workflows Could be In-Progress and In-Memory When Migration Occurs!

Preparing for In-Process Workflow Migration

Okay, now armed with this greater understanding we are ready to prepare for our workflow migration.  To start the process we must inspect the workflows on the MOSS 2007 Server Farm with concern for the following:

Ensure Workflows are Functioning Properly: Before attempting to perform a migration of In-Process Workflows you must first be sure the workflows are functioning properly

• Review ULS and Event Logs For Any Signs of Issues Related to Workflows
• Correct Issues Before Attempting Migration

Ensure DelayActivity – UnloadOnIdle is Set to True: You must also inspect any custom code to ensure it does not prevent the Workflow Dehydration Process

• Review Custom Workflow Code – Ensure UnloadOnIdle is Set to True
• Correct Any Code that Sets UnloadOnIdle to False

Run PreUpgrade Checker and Review Results: Run the preupgradecheck command on the Content Database(s) that is being migrated – inspect for additional key issues

• Issue ID: 956447 - The Declarative Workflow Actions File has been Modified
• Issue ID: 956448 - The Custom .ACTIONS Files Exist in the Farm
• Issue ID: 956449 - The Web.Config File Contains Modified Authorized Types for Workflows

If your Moss 2007 workflows meet all this criteria then they are ready for migration!

In part 2 of this article (coming soon!) I will provide the step-by-step process I use for migrating in-process workflows.

Many thanks to the great blog I found on the 14 folder.

I hope that helps!

Tom

Create a For Each Loop for Workflows Using SharePoint Designer 2010

(The technique described below is for SharePoint 2010, if you are using SharePoint Designer 2007 check out my other post SharePoint Designer Workflows 2 – Developing a For Each Loop for Workflows ).

1. Introduction: Many times when designing workflows there is a need to use a “For Each Loop”. As you may know a For Each Loop will continue to process an action against a list of items until all items in the list have been processed. While present in all programming languages whether declared, script or object oriented, the For Each Loop is not present in SharePoint Designer 2010 workflows, or the other GUI driven workflow tools I know. This article will help you build a For Each Loop for your SharePoint Designer workflow.

2. Scenario: In our simple scenario we want our workflow to run through each of several items in a list and to update each of the items Boolean “Processed” field from No to Yes (For Each list item update Processed field to Yes).

3. Explanation: Essentially we will have three workflows, one to create and delete a new item in the “Loop” list, and two others to update the Data list. The logic for the first workflow looks like this:

a. Create a new item in the Loop 1 list

b. Pause (allowing the Loop list workflow to run)

c. Update the current item's Loop count field

d. Delete the item created in Loop list

e. Log the actions taken

The logic for the second workflow looks like this:

a.  Calculate the Loop Count Value

b. Update the first item whose “Processed” field is set to No

c. Update the Current Item's Loop Count

d. Log actions

e. After 4 Loops Update the item in Loop 2 (thereby starting the third workflow)

f.  Reset the Current Item's Loop Count

The logic for the third workflow looks like this:

a.  Pause  (allowing the Loop 2 list workflow to finish)

b.  Update the first item whose “Processed” field is set to No

c.  Update Current Item Loop Count

d.  Log actions

4. Overview: To build a For Each Loop we will need three SharePoint Lists, the first list will contain our data, and the other two list will control the For Each Loop. For our example we will call the first list “Data”, the second list “Loop 1” and the third list "Loop 2". We will also need three SharePoint workflows, one, to create and delete items in the For Each Loop list, and two to update items in the Data list. To create the lists follow these steps:

a. From the SharePoint site create a custom list, call it “Data”

b. From the Data list add a custom Boolean column, call it “Processed”, set it’s default value to No and add it to the default view

c. Create 1 custom number field and call it "LoopCount"

d. From the Data list create 10 to 15 list items (this is sample content for our workflow)

e. From the SharePoint site create a second custom list, call it “Loop 1”

f. Create 1 custom number field and call it  "LoopCount"

g. From the Loop 1 list create 1 item, set the title fields value to  "For Each Loop 1", and set the LoopCount field's value to "0"

h. From the SharePoint site create a second custom list, call it “Loop 2”

i. Create 1 custom number field and call it "LoopCount"

j. From the Loop 2 list create 1 item, set the title fields value to "For Each Loop 2", and set the LoopCount field's value to "0"

5. To create the For Each Loop 1 workflow follow these steps:

a. From SharePoint Designer create a workflow that is associated with the Loop 1 list, call it “For Each Loop 1”

b. Set this workflow to start automatically when an item is created

c. Create 1 step for the workflow, call it “For Each Loop”

d. Create a condition – If Created By is not empty – this means the workflow will always run

e. Create a second condition – If  Current Item LoopCount is less than or equal to 3 – this will ensure the first set of actions runs only for the first 4 loops

f.  Create an action  – Calculate Current Item LoopCount plus 1 – this will increment the Loop Counter

g. Add an Update List Item activity, configure the activity as shown below:

h. Add a Update Current Item activity, configure it as shown below:

i. Add a Log to History List activity, configure the log to write “For Each Loop – Ran”

j.  Add an Else condition

k.  Add a Pause for 2 minutes – this will ensure the first set of triggered "Data" workflows has completed

l. Add a Update Item activity, configure it as shown below:

m.  Add a Update Item activity, configure it to update the original item in the Loop 1 as shown below:

n.  The complete workflow configuration should appear as below:

6.   To create the For Each Loop 2 workflow follow these steps:

a. From SharePoint Designer create a workflow that is associated with the Loop 2 list, call it “For Each Loop 2”

b. Set this workflow to start automatically when an item is changed

c. Create 1 step for the workflow, call it “For Each Loop”

d. Create a condition – If Created By is not empty – this means the workflow will always run

e. Add a Pause for 2 minutes – this will ensure the first set of triggered "Data" workflows has completed

f.  Add an Update List Item activity, configure the activity as shown below:

g.  Add a Update Item activity, configure it to update the original item in the Loop 1 as shown below:

h. Add a Log to History List activity, configure the log to write “For Each Loop – Ran”

i.  The complete workflow configuration should appear as below:

7. To create the Process Data workflow follow these steps:

a.  From SharePoint Designer create a workflow that is associated with the Data list and call it “Process Data”.

b. Set this workflow to start automatically when a item is changed

c. Create 1 step for the workflow, call it “Process Data”

d. Create a condition – If Created By is not empty

e. Create a second condition and Processed not equals No – this means the workflow will not run if the Processed equals no

f. Add a Create Item activity, create a new item in the Loop list, title the new item “New Loop Item”, and output to variable “idLoopListItem” of the type list ID, the activity should appear as below:

g. Add a Pause for Duration activity, pause for 1 minute

h. Add a Update Item activity, update the current item in Data and change the value of Processed to No.

i. Add a Delete Item activity, and delete the item in the Loop list that has the same id as the idLoopListItem or the item you just created (by deleting the item we will keep this list from growing too large in the future). The configuration should appear as below:

j. Add a Log to History List activity, configure the log to write “Processed – Ran”

k. The complete workflow configuration should appear as below:

8. Test the Workflows: To test the workflow we only need to start the For Each Loop workflow from our item in the Loop 1 List.

9. Error Messages: The last item created in the Loop list will have an error occurred in the workflow metadata field. This is because the last item to start cannot find any items that have not been processed. This error can be ignored; it’s part of the normal processing and will eventually be deleted by the Process Data workflow.

10.  I want to thank the many folks in the community who used the technique I described in my earlier blog SharePoint Designer Workflows 2 – Developing a For Each Loop for Workflows

11. Thanks: I want to acknowledge Ricky Spears for his article “Looping through Items in a SharePoint List with SharePoint Designer Workflows”, which provided the technique that I describe in this article.

Create a State Machine Workflow with SharePoint Designer 2010 - Part 2

Part 1 of this article is located here:
Create a State-Machine Workflow with SharePoint Designer Part 1

If you have already read part 1 of this article (and you should because part 2 won't make sense without it!) then you should be ready to construct a State-Machine workflow with SharePoint Designer 2010.

So now let's get to it!!

Open SharePoint Designer 2010 (SPD10), open your solutions site, and then click on the Workflows icon in the left pane navigation menu.  When the workflow tab appears in your design surface from the Quick Access Bar choose Reuseable Workflow.  We will create two reuseable Workflows, here is the data you need to fill out the workflow creation form:

• Workflow 1
• Name: Review Process Workflow
• Description: State-Machine
• Content Type: Review Process Library
• Statr Options: Manual and On Item Change
• Workflow 2:
• Name: Review Task Workflow
• Description: State-Machine
• Content Type: Review Process Tasks
• Start Options: Manual and On Item Change

Now let's edit the Review Process Workflow.  We'll start by creating 4 initiation form parameters to capture the participants of the workflow, th einitiationb paramters will be as follows:

• Submitter
• Compliance Officer
• Business Manager
• Quality Control

Here is the design for the initiation parameters:

Create 5 Steps for this workflow, here are the step names:

• Initialize
• Submitter
• Compliance Officer
• Business Manager
• Quality Control

Here is the design for Step 1, essentially, on the First Run only, we are updating the Review Process States and Review Process Roles metadata in the Review Process Library and then creating a new task in Review Process Task:

Here is the design for Step 2.  In this step we establish our normal State-Machine Workflow pattern, which is as follows:

• Check Three Conditions:
• Task Status
• Review Process Role
• Review Process States
• Create a new task item in the Review Process Task list with these values:
• Content Type ID
• Title
• Review Process Role
• Review Process States
• Description
• Workflow ID
• Assign To
• Create a Log entry to record the action
• Write a Log if no conditions are met for that step

Some of the finer points:

• Make sure the role is for the person Receiving the task
• Use the Current Item ID as the Workflow ID
• Use the Workflow Initiation Form parameters to assign the task to a participant 

Here is the design for Step 3.  This step, and all the additional steps, will follow the same pattern as step 2.

Here is the design for Step 4. This step will follow the same pattern as step 2.

Here is the design for Step 5. This step will follow the same pattern as step 2.

Once you have all these steps configured then save, publish, and deploy your workflow to the Task Process List.

Now for our Review Task Workflow.  This is also a very simple workflow, it's purpose is just to modify the three metadata values of the document in the Review Process Library.  By modifying these values the Review Task Workflow does two things - changes the State and starts the Review Process Library workflow (which will then create a new task based on the changed state).

Once you have all this step configured then save, publish, and deploy your workflow to the Review Task Library.

So by now you may be asking, "How does all this work?"  Let's go through a scenario to help explain:

1. Joe User uploads a document to the Review Process Library
2. Joe wants his document to be reviewed so he manually begins the Review Process Workflow
3. The Initian Form of the Review Process Workflow prompts Joe User for the account information of the four Role Based Participants involved in the workflow
4. Joe provides the acocount information and then clicks the Start button, this starts the Review Process Workflow
5. On the First Run the Review Process Workflow initializes values and then creates an initial Submitter Task in the Review Task List
6. The Submitter receives notification that he/she has a new review task
7. The Submitter reviews the task and chooses to change the state by modifiying the Review Process State value and then clicks OK
8. The Review Task Workflow modifies the state based metadata values of the document in the Task Process Library
9. Based on the new metadata values the Review Process Workflow creates a new task in the Review Task List
10. Another participant  receives notification that he/she has a new review task
11. This participant reviews the task and chooses to change the state by modifiying the Review Process State value and then clicks OK
12. Steps 8 through 11 continue to repeat until the Review Process Workflow is completed

I hope that helps!

Tom

Create a State Machine Workflow with SharePoint Designer 2010 - Part 1

Part 1 of this article is located here:
Create a State Machine Workflow with SharePoint Designer 2010 - Part 2


If you work with SharePoint Designer on a regular basis then you have probably built SharePoint Designer Sequential Workflows, and if you have built SharePoint Designer Sequential Workflows then you have probably been asked the question - "Can you build State Machine Workflows with SharePoint Designer?"  Well despite what you may have heard or been told the answer to that question is a definite "YES!" and this blog will show you just how that can be done.

To start with let's talk about the differences between a Sequential Workflow and a State Machine Workflow.  There are many good definitions for both types of workflows but one of the best explanantion I have read is the one provided by Stephanie Grima in her blog "[SharePoint] State Machine Workflow vs. Sequential Workflow (I have paraphrased her statements):"

 State-Machine workflows:

1.  State-machine workflows are workflows which are driven by particular state based events, for example:  

• Approved by Submitter
• Rejected by Compliance Officer
• Delegated by Business Manager
• Paused by Quality Control

2.  Until the workflow state changes, the workflow will not execute another action.

3.  The "path" of the workflow is dynamic and based what events the user executes.

4.  The workflow does not need to end, but instead can continue to execute based on changes in state.

Sequential workflows:

1. Sequential workflows are very static, they work like a flowchart, for example:  

• Complete Step A
• Complete Step B
• Complete Step C

2.  Sequential workflows are useful when there is pre-determined sequence of events required to complete the task.

3.  The"path" of the workflow is rigid and based on what sequential actions are defined by the developer.

To put it succinctly, State Machine Workflows can take any path based on process state, Sequential Workflows can only take one path based on process flow.

So, now that we understand the theory let's put it into practice by creating a State Machine Workflow in SharePoint Designer (SPD) 2010.

Our Review Process Roles are as follows: 

• Submitter 
• Compliance Officer 
• Business Manager 
• Quality Control 

Our Review Process States are as follows:

• Policy Review Started
• Policy Review Ready for Compliance Officer Review
• Policy Review Returned for Correction to Submitter
• Policy Review Ready for Business Manager Review
• Policy Review Returned for Correction to Compliance Officer
• Policy Review Ready for Quality Control Review 
• Policy Review Returned for Correction to Business Manager 
• Policy Review Completed

The Compliance Officer, Business Manager or Quality Control can approve or reject the policy, and if they do they can return it back to any step in the process.  It is also true that the Submitter, Compliance Officer and Business Manager can approve the policy, and if they do they can move it ahead to any step in the process.  Here is our simple process diagram:

OK, now for the basic structure of our SPD 2010 workflow solution.  Essentially the solution consists of two workflows, the Review Process Workflow and the Review Process Task Workflow.  As their names imply the Review Process Workflow manages the main review process, and the Review Process Task Workflow task the workflow participants.  The interaction of these two workflows can be represented as shown below:

So let's start building our State Machine Workflow. Our build starts with Content Types at the Site Collection Level -  Review Process Task and Review Process Library.  Here is the structure of the Review Process Task Content Type:

The one additional modification we will need to make is to change the items in the choice list for the Task Status field.  Delete all the existing choices and simply add two choices - "Approve" and "Reject", and make sure there is no default choice configured.

And here is the structure of the Review Process Library Content Type:

Again, the one additional modification we will need to make is to change the items in the choice list for the Task Status field. Delete all the existing choices and simply add two choices - "Approve" and "Reject", and make sure there is no default choice configured.

Notice that both content types make use of three custom content coulmns Rerview Process Roles, Review Process States, and Workflow ID. Here is the structure of Review Process Roles choice column:

• Submitter
• Compliance Officer
• Business Manager
• Quality Control

And here is the structure of the Review Process States choice column:

• Policy Review Started
• Policy Review Ready for Compliance Officer Review
• Policy Review Returned for Correction to Submitter
• Policy Review Ready for Business Manager Review
• Policy Review Returned for Correction to Compliance Officer
• Policy Review Ready for Quality Control Review
• Policy Review Returned for Correction to Business Manager
• Policy Review Completed

The Workflow ID column is just a simple number column set to have 0 decimal places.

Next we need to create the Review Process Library as a document library and the Review Process Task as a task list. Once these are created replace the default Content Types with our custom Content Types. This will make the default Content Type for the Review Process Library the Review Process Library Content Type and the default Content Type for the Review Process Task list the Review Process Task Content Type. 

OK, now for the good part, we need to make two reuseable workflows - Review Process Workflow and Review Task Workflow.  As you may have guessed, the Review Process Workflow will use the Review Process Library Content Type, and the Review Task Workflow will use the Review Process Task Content Type.  (To see how to create reuseable workflows in SHarePoint Designer click here).

The psuedo logic for the Review Process Workflow is as follows:

• Submitter
• State = Policy Review Started
• Or If Approve and Sate = Policy Review Ready for Compliance Officer Review
• Or If Approve and State = Policy Review Ready for Business Manager Review
• Or If Approve and State = Policy Review Ready for Quality Control Review
• Then Create New Task
• Compliance Officer
• If Reject and Sate = Policy Review Returned for Correction to Submitter
• Or If Approve and Sate = Policy Review Ready for Business Manager Review
• Or If Approve and Sate = Policy Review Ready for Quality Control Review
• Then Create New Task
• Business Manager
• If Reject and Sate = Policy Review Returned for Correction to Submitter
• Or If Reject and Sate = Policy Review Returned for Correction to Compliance Officer
• If Approve and Sate = Policy Review Ready for Quality Control Review
• Then Create New Task
• Quality Control
• State = Policy Review Completed
• Or If Reject and Sate = Policy Review Returned for Correction to Submitter
• Or If Reject and Sate = Policy Review Returned for Correction to Compliance Officer
• Or If Reject and Sate = Policy Review Returned for Correction to Business Manager
• Then Create New Task

The psuedo logic for the Review Task Workflow is as follows:

• If State has Changed then Update Review Process Library
• Else Log "No Change"

From the psuedo logic we can see that the Review Process Workflow contains the logic to capture all the possible states and then creates the appropriate task for the appropriate role based on that state.  On the other hand the Review Task Workflow simply updates the Review Process Library with the current state based on the outcome of the task.

Now let's build our State-Machine Workflow!!! I'll cover the steps for construction in my next article - Create a State Machine Workflow with SharePoint Designer 2010 - Part 2 (Coming Soon!!!).

References:

Creating State Machine Workflows using SharePoint Designer 2007

Creating State Machine Workflows using SharePoint Designer 2007: Addendum

 Mea Culpa — SharePoint Designer *CAN* Create State Machine Workflows

Why You Should Try The New Sharepoint Designer 2010 Workflows

If your organization hasn't tried the new SharePoint Designer (SPD) 2010 workflow capabilities, this blog may help you make a strong case as to why they should:

Cost: SPD workflows are built with SPD 2007 and SPD 2010, both of which free products

ROI: SPD 2007/2010 workflows leverage your existing investment in SharePoint

Support:

• Books: There are many professional books available to help guide the SPD WF developer
• Blogs: There are many professional blog sites available to help guide the SPD WF developer
• Forums: There are many professional forums available to help guide the SPD WF developer
• Community: There are hundreds of professional SPD WF developers
• Vendor:

            - Microsoft provides abundant tutorials, virtual labs, and technical articles
            - Microsoft responds rapidly to any technical issues with patches and updates
            - Microsoft can provide advance trouble shooting for this product

Ease of Use:

• Graphical Design Tool: SharePoint Designer has a powerful yet intuitive workflow editor in SharePoint Designer 2010 that allows nested logic, sub steps, and more. For a quick “How To” see this article - Introduction to Designing and Customizing Workflows

• Task Actions:

o Task Actions: SPD 2010 includes new task actions that you can use to model all sorts of business workflows in your organization. This creates tremendous flexibility – you can edit and customize almost any aspect of the task process (For example, the default settings in a task process mean that approval must be unanimous by all workflow participants, but you can change this so that approval means a simple majority or even a certain percentage, such as seventy percent)

o For a quick “How To” see this article - Introduction to Designing and Customizing Workflows

• Conditions:

o Conditions Support Multiple Workflow Scenarios: SPD WF support conditions that can be used with an Impersonation step, Content Type Workflows, or Site workflows

o For a Complete Listing of Conditions see - Workflow Conditions In Sharepoint Designer 2010 a Quick Reference Guide

• Actions:

o Actions Supporting Multiple Workflow Scenarios: SPD WF’s provide a set of conditions that can be used with Core Actions, Document Set Actions, List Actions, Relational Actions, Task Actions, Task Behavior Actions, and Utility Actions

o For a Complete Listing of Conditions see - Workflow Conditions In Sharepoint Designer 2010 a Quick Reference Guide

Microsoft Visio - Graphical Design Tool:

• With Microsoft Visio Premium 2010, you can create a workflow in Visio and then export it to Microsoft SharePoint Designer 2010

• For a quick “How To” see this article - Create Import and Export Sharepoint Workflows in Visio

SPS 2010 OOTB Workflows:

• Common Design Tool: SPS 2010 OOTB workflows can be extended by using the same SPD WF design tools that are used to create a SPD WF from Scratch

• Reusable Design: A SPS 2010 OOTB workflow that is extended using SPD will be reusable because it will be created as a Content Type Workflow and can be deployed across other sites, site collections and farms using a solution package (.wsp file)

• Advance Customization with Visual Studio: An SPS 2010 OOTB workflow that is extended using SPD can be even further extended by importing the SPD WF into Visual Studio

Visual Studio WF:

• Import SPD WF: Visual Studio 2010 has the ability to import a .wsp package from a SPD WF as a Visual Studio workflow project, therefore, SPD WF designs can be reused and extended by using Visual Studio 2010

• For a quick “How To” see this article - Walkthrough: Import a SharePoint Designer Reusable Workflow into Visual Studio


List Workflows:

• List\Library: A list workflow is the type of workflow that was available in SharePoint 2007, and because it has the context of the list or library for which it was created, list workflows automatically have access to the values of the custom fields for the list item on which they will run

• Not Reusable: List workflows cannot be made available to other lists or libraries on the site they were created on or on other sites

• Custom Fields: If you know that you will only need the workflows you are designing for a specific list, the list workflow has the advantage of automatically making available the custom fields of the lists

Reusable List Workflows:

• Site: You can create a reusable list workflow in the top-level site in the site collection, and that workflow can be associated to any list, library, or content type in the site collection

• Subsite: You can also create a reusable list workflow in any subsite in the site collection; this workflow is available for reuse anywhere in that particular subsite

• Export as a Template: You can export a reusable list workflow as a template from one site and then upload and activate that workflow template in a different site

• Common Columns: Reusable list workflows, by default, don’t have the context of a specific list or library, therefore, they provide only the columns that are common across lists and libraries such as Content Types, but reusable SPD WF’s are not limited to Content Types

• Associated Columns: If your reusable workflow requires certain columns to be present in the list or library that you associated it to, you can add those columns as association columns (association columns get added automatically to a list or library when a reusable workflow is associated to that list or library)

• Ease of Deployment: A reusable list workflow can be deployed across other sites, site collections and farms using a solution package

• Advance Customization with Visual Studio: A reusable list workflow can highly modified and extended because it can be imported into Visual Studio 2010

• For a quick “How To” see this article -Create a site workflow and modify its form using InfoPath Forms 2010

Site Workflows:

• Site Level: A site workflow is associated to a site — not to a list, library, or content type so unlike most workflows, a site workflow is not running on a specific list item (because of this, many of the actions that are available for items are not available for site workflows)

• Example Scenario: For example, you can create a site workflow as a way for people to provide feedback about your site

• For a quick “How To” see this article — Introduction to designing and customizing workflows

Deployment:

• Deploy Directly:

o You can directly associate a SPD WF with a list, library, content type, or site

o For a quick “How To” see this article - Workflow deployment process (SharePoint Server 2010)

• WSP Files:

o You can deploy a SPD WF as a workflow template (.wsp file). The .wsp file can then be used to deploy the workflow on multiple sites and site collections

o For a quick “How To” see this article - Deploy a workflow as a WSP file (SharePoint Server 2010)

Visio Integration:

• Two Way Integration:

o To or From SPD: In Microsoft SharePoint Designer 2010, you can import a workflow created in Microsoft Visio Premium 2010 or export a workflow to Visio for viewing

o For a quick “How To” see these articles - Transfer workflows between SharePoint Designer and Visio

• SPD WF Template Shapes:

o WF Templates: Visio Premium provides SPD WF Templates that not only allow BA’s to design detailed workflow flow charts, but also allow the SharePoint Designer to quickly convert and deploy those workflows

o For a quick “How To” see this article - SharePoint Workflow template shapes guide

• Ease of Conversion:

o Click Button Conversion: Workflow designs created in Visio Premium 2010 can be converted to SPD WF’s with only a few clicks – Import Workflow, Name Workflow, Identify Workflow Type

o For a quick “How To” see this article - Transfer workflows between SharePoint Designer and Visio

• Workflow Visualization:

o Track the Progress of the Workflow Visually: Using SharePoint Designer 2010, you can enable workflow visualization on the workflow status page – this enables users to see the workflow in progress!

o For a quick “How To” see this article - Transfer workflows between SharePoint Designer and Visio

InfoPath Integration:

• Workflow Forms:

o Advanced Workflow Forms: You can use Microsoft InfoPath 2010 to create advanced forms for SPD workflows

o Design Once – Use Many: Because you are using InfoPath with SPD WF’s, developers won’t have to create two separate forms, one for use on the server and one for use in the client (InfoPath 2010 gives you the ability to create symmetrical forms; that is, forms that look and operate exactly the same whether they are displayed in the SharePoint Server 2010 Web interface or within a Microsoft Office 2010 client application)

o For a quick “How To” see this article - InfoPath Forms for Workflows

• Client Based Forms Driven Applications with Workflow:

o Client/Server Applications: Client based InfoPath applications can use SPD 2010 WF’s to provide a tightly integrated client/server workflow capability

o For a quick “How To” see this article - InfoPath 2010 Enhanced Integration with SharePoint Server 2010 and Its Implications When Designing Forms for Applications