An essential service provided by Access Workflow Designer is that of creating and executing a workflow process. 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 Access Workflow Designer provides a graphical view of the workflow process that can be easily automated, extended, and edited from within the tool.
In its simplest form, the workflow process automates and enforces the order of the tasks in the process. For example, a user creates a new issue and assigns it to another user, who then resolves the issue and assigns it back to the original user, who then can close the issue. By defining the order of the tasks in the workflow process, the team solution can ensure an issue is resolved before it is closed.
The conceptual model for a workflow process includes states and actions. A state is a discrete value of the state property of an item. For example, the state of an issue defines where that issue is in the workflow process, such as Resolved or Closed. An action defines the operations that can be performed on an item. One special type of action is a transition, which moves the item from one state to another. Actions are triggered by database changes.
Note For a more detailed description of the workflow features, see The Workflow Engine Model in the Access Workflow Designer Developer's Guide.
In the following diagram of a workflow process used in the Issue Tracking solution, the circles represent states and arrows represent actions.
Using script with workflow actions can make your workflow process very powerful. Before adding script to workflow, it is important to understand:
There are seven types of actions that can be used in your workflow process. These actions define the operations that can be performed on an item in a given state. Each state can have a single Enter, Exit, Create, Change, and Delete action and multiple Timeout and Transition actions.
Note Although each state can have multiple transition actions, you cannot have multiple transitions between the same two states. So, from a state called Resolved, you might have transitions to Closed and Activate, but you would not have two transitions from Resolved to Closed.
Certain actions are created by default by the Workflow Process wizard. For example, your first state is always assigned the actions of Create and Change. These actions appear in the workflow process diagram with their "friendly" names of "New" and "Edit." You can designate friendly names for all actions except Enter and Exit.
The available workflow actions and their default names are listed here:
Action | Default name | Description |
Transition | <none> | Specifies a transition from one state in the workflow process to another; must designate a name and the next state. |
Create | New | Makes it possible for an item to be created in a given state. |
Delete | Delete | Makes it possible for an item to be deleted in a given state. |
Change | Edit | Makes it possible for an item to be updated in a given state without any state-transition. |
Enter* | OnEnter<State Name> | Triggered whenever transitioning into a given state regardless of the previous state in the transition. |
Exit* | OnExit<State Name> | Triggered whenever transitioning out of a given state regardless of the previous state in the transition. |
Timeout | OnTimeout<State Name> | A time-based action; for example, if an item remains at a certain state for more than a specified length of time, an action can be triggered to mark that item as overdue. |
*Cannot be renamed
To add functionality to the workflow process, you can add script to automate or validate tasks. When you add a workflow action, two workflow script procedures are created for you. These script procedures are the events used to trigger code whenever an action is performed.
The validation script procedure is the first event to be executed and is typically used for error handling. This script procedure is always a function and by default returns a value of True. For example, script associated with this event can verify the information the user typed is valid before executing the action event that is dependent on the information. You can modify validation functions to make them conditional — for example, only perform this action if a certain person is logged on or if it is a certain day of the week.
Next, if validation is successful, the action script procedure is fired. The action script procedure is always a subroutine and typically triggers code that performs an operation associated with the action. For example, when an Update action is performed, the script associated with the Update action event can send an e-mail notification. For more information, see Workflow Scripting.
Script procedure names are created as a combination of the script procedure, the action, and the State ID. Each state in a workflow diagram is assigned a state ID. The State IDs are integers, starting at one and increasing by one. In our example, the Active state is one, the Resolved state is two, and so on.
When you assign a Create action to the Active state, the script procedure names are ValidateOnCreate_1 and OnCreate_1. If you add a Change action, the associated script procedures appear as ValidateOnUpdate_1 and OnUpdate_1. If you add a Change action to the Resolved state, the script procedures are named ValidateOnUpdate_2 and OnUpdate_2.
For each action, there are two script procedures — validation and action. Developers can add code to script procedures associated with each action. You do this in the Workflow Process pane in the designer.
On the Design tab of the Workflow Process pane shown here, the state called Active has three actions associated with it: New, Edit, and Active_Resolved. These actions are displayed in the Actions for: section of the Workflow Process pane.
For each of these actions on the Active state, there are two script procedures. The validation script procedure is the first event to be fired. Next, if the validation is successful, an action script procedure is fired. These script procedures are fired whenever an action is performed.
On the Shared Script tab of the Workflow Process pane shown here, you can view the script associated with these script procedures. You can add script to the Sub OnCreate_1() event (for the new action) in this window.
For more information about adding script to workflow actions, see Scripting Workflow Actions in the Access Workflow Designer Developer's Guide.