Initiating Workflow for a Record
Workflow begins when a record is inserted into the workflow-enabled database, and you invoke the workflow process every time you save a record. To enter or save a record, you first must enter a valid state ID value into the modStateID column of that row.
Workflow is governed by the state ID number in the modStateID column. The modStateID column was added to the workflow-enabled table when the table was first registered for workflow. Each state in the workflow process has a state ID number that was assigned at design time automatically. This number is entered in the modStateID column, where it serves as the basis for determining what events are valid currently for each record. To set a value in the modStateID column, you can use the Office Developer Workflow Toolbar control in a data access page user interface, or you can write your own code to do it.
If you are using the Workflow Toolbar control in your user interface, it initializes the modStateID column to the value of the first state chosen by the user when the user saves the record for the first time, and it dynamically makes all permissible options available to the user each time the record is opened. If there is more than one possible state at the beginning of your workflow diagram, the user can to choose which state is the appropriate one for the new item.
If you are not using the Workflow Toolbar in your user interface, you must write code that accomplishes the same thing. To determine which events are valid currently for a record, compare the modStateID value in that record with the view called <*tablename>*WorkflowView in that database, which details all the events that are possible from each state according to the workflow diagram.
For an example of code that sets the initial modStateID for a record, look at the script in Walkthrough: Creating a Workflow Application for SQL Server with a Visual Basic Interface.
Moving from One State to the Next
If you have created your user interface using data access pages and the Office Developer Workflow Toolbar control, then users are presented with controls that make it possible for them to move to a subsequent valid state, and only to a valid state, every time they save a record.
Each time the user saves the record, the modStateID value is changed to that of the selected state, and the events associated with the transition from the current state to the next state are triggered. If there is more than one possible state to which to move, the user must choose the correct state based on business rules.
If you are not using the Workflow Toolbar in your user interface, you must include code that checks the <tablename>WorkflowView view for the next valid states, based on the record's current modStateID value, and presents those states as options to the user. Then, your code must change the record's modStateID to that of the next selected state. You can find the modStateID for each state in the <*tablename>*StateLookup table.
For an example of code that presents users with a record's next allowable states, look at the script in Walkthrough: Creating a Workflow Application for SQL Server with a Visual Basic Interface.
See Also
Understanding the Workflow Process for SQL Server | Adding Workflow Processes to Databases | Designing Workflow Processes for SQL Server | Controlling Permissions for Events | Testing Workflow Processes for SQL Server