The workflow process is a series of tasks or actions, the order in which they must be performed, permissions defining who can perform them, and script that is executed for each action. The workflow engine is a component in the Access Workflow Designer infrastructure that makes workflow possible.
The workflow engine is used to enforce the workflow definition and execute workflow actions. When a user table is enabled for workflow, workflow insert, update, and delete triggers are created for that table. Any change made to an item in the table will execute the corresponding workflow trigger that in turn calls a stored procedure, which invokes the workflow engine.
The workflow engine has three functions. First, it verifies whether the change is valid for the current workflow state. For example, if there is no Delete action defined for the current state, the engine does not make it possible for users to delete an item in that state.
Second, it checks if the current user has permissions to execute the workflow action. For example, if the action is a transition from Active to Resolved, the engine checks if the current user is permitted to execute this particular action.
Third, if the action is valid and the user has execute permissions, then the workflow engine evaluates the Condition script. If the condition is True, it executes the action procedure. If the action completes successfully, the engine invocation returns success, and the trigger commits the change. If an error occurs while executing the Condition or Action scripts, the engine reports the error to the trigger. The trigger raises a SQL Server error and rolls back the change.
Access Workflow Designer provides three table-level options that control the way the workflow engine works. The options can be set on the General tab of the Workflow Process pane and are stored in the modObjects table.
It is recommended you run the workflow engine in a separate process until you have fully debugged and tested your workflow process. The default is to run in a separate process. This choice may be made on a table-by-table basis.
Note All workflow code runs under the context of the user account you configure for the workflow engine. The permissions granted to this account on the server depend on the team solution’s requirements and the sensitivity of other data on this computer.
Every workflow-enabled table is required to have a status column that holds the workflow state and moves each item through the workflow process. This status column must be an integer data type and must have a foreign-key constraint with a keyword lookup table that stores the names of the workflow states. For details on data types, see Database Schema Design Guidelines.
The status column can be pre-existing or created by the Workflow Process wizard. If you are using a pre-existing column, be sure it meets the data type restrictions mentioned earlier and you have created the lookup table containing the StatusID and Status Description columns (your column names may be different).
When using the Workflow Process wizard to create a column, you enter the state names and set the order. The wizard creates the associated lookup table and assigns the values to the created states based on the order you indicated.
To enable initialization of the workflow state for existing items, the workflow engine makes it possible for transitions from Null into any valid workflow state.
For details about adding workflow, see Adding a Workflow Process to your Solution.