NOTE: This is a workaround to mimic state-machine behavior from a sequential workflow developed using SharePoint Designer 2007.
To get up to speed with developing SharePoint workflows using Visual Studio 2005, watch the HOWTO: Series of SharePoint Workflow HOW-TO Videos by Robert Shelton.
Sequential workflows are fairly straight forward to create whether you are developing in Visual Studio (VS) or SharePoint Designer (SPD) 2007 and can be used to model most single or multi-step approval workflows. The only downside to Sequential workflows is that you cannot make the workflow jump back to a previous step/activity that may or may not have already executed or, in other words, cannot move from being in one state to the other like a state machine workflow. For most workflow developers/creators, this is reason enough to go for workflow development in VS. While VS worksflows work just the same as those develped using SPD 2007, keep in mind that SPD 2007 is more suited for managers and/or business analysts (non-developers) who may be reluctant to assign workflow development task because of time, resource, and budgetary constraints. This is where the following intuitive solution may come in handy. Lets look at a hypothetical scenario in detail.
Scenario:
A technical document needs to be analyzed, revised (if need be), and approved to exist in the repository.
Actors:
- Repository Managers
- Content Analysts
- Managers
Workflow (see state-machine diagram above):
- Document Uploaded to MOSS 2007 Document Library. [Document Status updated to Awaiting Assignment]
- Repository Manager assigns document to Content Analyst. [Document Status updated to Pending Analysis & Review]
- Analyst views documents, makes required changes, and submits document to Manager for approval. [Document Status updated to Awaiting Approval]
- If Manager rejects document, document routed to Content Analyst. [Document Status updated to Pending Analysis & Review]
- If Manager approves document, it is kept in the document library. [Document Status updated to Approved]
The above workflow is pretty straight-forward, and could easily have been created using SharePoint Designer if it were not for step 4, which can happen any number of times until the document gets approved by the Manager. To create a State Machine behavior in a SPD 2007 workflow, create a separate list (say "Content Approval Workflows") to maintain the state of the workflow at any given point in time. A separate list also ensures that the user cannot go and manually change the status. Also, 2 workflows would need to be created; one on the actual document library (called "Core.NET Content") that houses the uploaded documents, and the other on the Content Approval Workflows list. The 2 lists we are working with are summarized below:
Core.NET Content
List Type: Document Library
Workflow Name: Approval Initiation Workflow
Workflow Executed: On Item creation
Core.NET Approval Workflows
List Type: Custom List
Workflow Name: Approval Processing Workflow
Workflow Executed: On Item creation
; On Item update
Columns: Title, Document Status (Choice Column with each of the workflow states), WorkflowInstance Id (Lookup column that references ID column in the Core.NET Content document library)
To get an even better idea, take a look at the following diagram.
The steps modeled in the diagram above are:
- Document uploaded to Core.NET Content Document Library.
- Item creation in Core.NET Content Document Library kicks off Approval Initiation Workflow which creates an item in the Content Approval Workflows list (with the Document Status value set to "Awaiting Assignment") and completes.
- Creation of item in Content Approval Workflows list kicks off the Approval Processing Workflow that performs the following operations recursively i.e. completion of every step below updates the Document Status column value and in-turn starts another Approval Processing Workflow instance on the same item.
- Start on item creation - If Document Status is "Awaiting Assignment", create a task in the Tasks list for Repository Managers, using the "Collect Feedback from user" activity, assign the task to the username entered in the task, and set the Document Status value to "Pending Analysis & Review".
- Start on item update - If Document Status is "Pending Analysis & Review", create a task in the Tasks list for the user in the Content Analysts group who was assigned the Analysis & Review task in the preceding step, using the "Collect Feedback from user" activity, and set the Document Status value to "Awaiting Approval" when the user clicks the "Complete Task" button.
- Start on item update - If Document Status is "Awaiting Approval", create an approval task in the Tasks list for Managers using the "Collect Feedback from user" activity, to either approve or reject the document. If Manager approves the document, set the Document Status value to "Approved", else set the Document Status value to "Pending Review & Analysis" which re-starts the workflow from step 3-2.
Note: The IF condition on every step ensures that the workflow takes only one path depending on the value for Document Status. Also, using the "Collect Feedback" activity in SPD 2007 ensures that the workflow stay in the wait state until the actor specifies the required input, and clicks the "Complete Task" button.
[UPDATE: Read the process of creating the State-machine workflow using SharePoint Designer 2007 in the following post here]
Hi,
Thanks for the post. I just had one quick question. Have you implemented this solution in Sharepoint Designer?
I have a feeling that the secondary workflow that gets triggered when an item is changed will create an infinite loop as it changes the list item itself. I developed something very similar to your approach and it generated an infinite loop (sending me 10s of e-mails within a few minutes.) Did you experience something similar? Do you know a way to avoid the infinite looping?
Thanks,
Feel free to contact me at the following e-mail:
sarpyeletaysi_at_coop-systems_dot_ com
Yes, I have implemented this solution and it works like a charm.
The logic here is pretty much the same as that used in coding recursive function; an IF condition within the workflow steps can be used to terminate the workflow using the "Stop Workflow" activity. I have received other queries and comments regariding this post, and I hope to blog more about it in the coming days. Stay tuned!
I'm in agreement with "Anon" above. What I've seen is that if the workflow changes the values in fields of the Current Item, Sharepoint Services re-invokes the workflow and gives it the updated record to work on. This is an unwanted side effect for my purposes. If the subsequent invocations continue to modify the list item contents, the workflow will run indefinitely.
What I meant was, how does any particular workflow invocation "know" that it is not wanted and should stop itself, you see what I mean? Can be done, sure, but...not for the timid.
I screwed up and posted my email account, can you please remove it from my comment? I would greatly appreciate it as the spam has already started...*sigh*. Thanks for a great blog.
Harv's deleted comment was:
And one more thing. I did some emperical testing and discovered that (at least in our installation) the workflow recursion occurs when the list is a "Project Tasks" list, but NOT if if it is a "Custom List". Very strange.
I have this technique wirking very well. I have a state column in my secondary list. My first step is an IF-THEN-ELSEIF that checks each of the possible states, and assigns a Review task with feedback (Get Data From User).
The second step checks the user responses and select the new state. The final step changes the value of the state column as the last action.
There should be a "final" state that does not cause a change in the state column, making the secondary workflow cease.
This workflow is working fine.But i need the main workflow to continue after the secondary(loop) workflow gets over.Please help me
@Ajay
You cannot really re-start the same instance of the primary workflow after completion of the secondary workflow. However, you can still create/add a new item in the primary workflow list, which would kick-off a new instance of the primary workflow, possibly using values from the (just-concluded) secondary workflow instance. Make sense?
hi, my question is really not about the workflow you implemented but about the program you used to sketch the pictures of the workflow. Can you please tell me what program did you use?
You can try using Microsoft SketchFlow. However, the diagrams in this blog post I created inside Adobe Flash and exported to an image file.
Thank you very much for your quick answer.
@Adnan re: restarting the primary workflow
Rather than stopping and restarting the primary workflow, could you not just have the primary workflow wait until some condition created by the secondary workflow is met?
@shmee
In a way, the primary workflow is in a wait state when it stops executing, while the secondary workflow executes. One of the ways to re-kickoff the primary workflow is to specify item-edit as one of the conditions for workflow execution. That way, if the secondary workflow wanted to start the primary workflow at any stage, it would just update the SharePoint list item (SPItem), and a subsequent evaluation of a condition in the first activity of the primary workflow can decide how and what to process based on the value updated by the secondary workflow.
I have been visiting various blogs for my term papers writing research. I have found your blog to be quite useful. Keep updating your blog with valuable information... Regards
thanks for sharing. nice post..
What a great post... But, have you implemented this on Sharepoint Designer before? thank you.
What did you use to create the diagrams on this post? I love the look!
@Matthew
Thanks! I created the diagrams in Adobe Flash and exported to an image.
I really love to read articles that have good information and ideas to share to each reader. I hope to read more from you guys and continue that good work that is really inspiring to us...
logo design blog