How can I create a basic multi-step State Machine workflow without any custom coding from Visual Studio or customized Visio or InfoPath workflows within Sharepoint Foundations 2010 or Sharepoint Server 2010?
1
-
NOTICE! This has only been tested in Sharepoint version 2010. There is supposedly a method for pre-2k10 versions of Sharepoint, but I do not have that info here.– Thomas WardMay 25, 2012 at 13:53
Add a comment
|
1 Answer
A basic state-machine workflow doesn't require any real customized coding, except for complex state machines. Most applications won't require complex coding. However, some will, so if a state machine workflow you create within Sharepoint Designer 2010 (NOT one created with Visual Studio or Visio) with this answer does not allow you to do the functions you need, you will probably need to customize one within VS2010 or Visio.
You can make a state machine workflow within Sharepoint Designer without any really customized code. It's not too hard, so I'll outline it here (courtesy of some posts from the Microsoft TechNet forums in this thread):
1) Create a field in the library/list to track the state (a choice field works nicely here) with logical values for the states (like Initiating, Manager Approval, Finance Approval, etc.).
2) Set the workflow to run after every change.
3) Add steps to the workflow for each level in the choice field. So if you have four states in that choice field, you would have four steps in the workflow, one for each of those choices in the field you created in step 1.
4) Create some procedure for the choice field to be modified. This can either be an automatic process or a manual process. If you need omni-directionality (a method to allow the state to be changed to any other state by an admin), then the field is visible to the user, and they can change the state as is necessary (NOTE: Using such a method has a huge risk of permissions errors, unless you add in who can or cannot set a specific state to the workflow, like an error checker). You could also have the workflow automatically set the state after approval or disapproval.
[OPTIONAL] 5) Optionally create a mechanism to ensure that the workflow only runs when the state is changed. For example, create another field called OldState (and make sure it doesn't show up on the views for the user). So, the first step of the workflow would have a condition: If currentstate = oldstate, then the state didn't change, and stop the workflow. If currentstate <> oldstate, then the state has changed, keep running the workflow, and set oldstate = currentstate.
(Step 5 is a direct copy from m g's post in the thread linked earlier in this answer (from Microsoft TechNet forums))