Understanding the Workflow Process for SQL Server

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

A workflow process is made up of a series of states and events, the order in which they must occur, and (optionally) the script that is executed for each event. In its simplest form, a workflow process enforces the order of tasks. The workflow process is the center of a workflow project, which also includes the database table hierarchy. When you add a user interface to a workflow project, you create a complete workflow application.

Before you can build a workflow process, you must have a Microsoft® SQL Server™ database and have database owner (dbo) permissions. In addition, you must have a solid plan for the business processes you want to track, including the tables involved, the roles involved, and when the events are permissible.

For a basic issue tracking project, you might want to specify the states that you want to require and prevent an item from moving to the next state until the previous one is done. For example, before moving from Active to Closed, an issue must go through the state Resolved. This would require a basic linear-workflow diagram.

Basic states and events identified for issue tracking

If your workflow application is more complex, you can add alternate possible states and transitions to your workflow process. For example, after an issue has been closed, perhaps a user in the manager role must be able to reopen it. This requires adding an additional state, called Reopened, and the appropriate events, including two transitions, Reopen and Reresolve.

When you add the first state to the workflow process, the Workflow Designer adds a new column called ModStateID to your database table. Each state that you add to the workflow diagram has a state number assigned to it. When the item moves to another state, the ModStateID number changes to that of the new state.

After you have opened your database in the Workflow Designer, begin creating your workflow process by following these steps:

1. Select the main table that is governed by the workflow. For more information, see Adding Workflow Processes to Databases.
2. Add states, events, and transitions to the workflow diagram. For more information, see Designing Workflow Processes for SQL Server.
3. Place restrictions on who can perform certain events if desired. For more information, see Controlling Permissions for Events.
4. Test your workflow process. For more information, see Testing Workflow Processes for SQL Server.
5. Start using the workflow. For information on how a record starts the workflow process and how records move from one state to the next, see Starting the Workflow for SQL Server.

See Also

Building Workflow Applications for SQL Server | Understanding the Workflow Application | Setting up a Table Hierarchy | SQL Server Workflow Databases