Access Workflow Designer uses views to access each database table. SQL views are similar to a virtual table or a stored query and server as a consistent, SQL-based interface to data. Views control the access to data in user tables using access permissions on views and row-level permissions. Views for detail tables handle column and table permissions for their table. For row-level security, the detail view looks up the hierarchy chain and enforces permissions as defined in the main table.
Tables that do not require views initially can add a lookup or permissions table and, therefore, may eventually require a view. It is recommended you design your database to meet future requirements and use views of your data.
The views created by Access Workflow Designer have the same schema as their underlying tables, with synonym columns. The views are registered in the modObjects table and have the table ID as the parent ID.
Tables in a solution hierarchy are treated, for most purposes, as independent tables. Views are created for each main and detail table. Those views are the building blocks for data hierarchies. Views do not span over more than one data table, however (for example, a flat recordset that includes a column from two or more user tables).
For more information about SQL Views, see the SQL Server Books Online.
When creating a team solution, the Access Workflow Designer extends your solution database by creating a number of system views. These views exist in the solution database and provide developers with controlled access to data in the modSystem database. Two views are associated with user tables.
| View | Description |
| modUserList | Filters the user directory and selects all the users of the current team solution. |
| <table>View | Enforces column-level and row-level security for a user table. |
| <table>WorkflowView | Exposes selected columns from the <table>Workflow table. Filters only those rows in the workflow table that describe actions on which the user has execute permissions. |