The ability to view or change certain pieces of information often needs to be restricted based on a user's role. For example, in a payroll solution, an employee and manager might be allowed to view the employee's salary, but you would want only the payroll clerk to have the ability to change the salary in the solution.
Access Workflow Designer provides role-based security based on security information from SQL Server and Windows NT. Roles are defined by the developer using Access 2000 database security tools and are based on the SQL Server database roles.
Permissions specify what kind of access a user has to data or objects in the team solution database. For example, if a user has read permissions for a table, the user can view or retrieve but not edit data in the table. These permissions can be modified using Access 2000.
Security can be managed at the team solution level by adding or removing users from the solution. Setting security at the solution level controls access to both the team database and the team Web site. Permissions can also be applied at a table level or at a row level.
These security features leverage the database-, table-, and column-level security that SQL Server provides. Access Workflow Designer also extends the SQL Server security model by enabling row-level security and workflow action security.
Row-level permissions make it possible for users to set permissions on individual rows on a table. Only main user tables can have row-level permissions set. When you define permissions for a main table, those permissions are also enforced on related rows in any detail user tables.
Row-level permissions are enforced for write operations using triggers on the associated table. Read permissions are enforced by requiring all access to the table to be performed through a base view that Access Workflow Designer creates and by locking the base table. Permissions settings are also preserved when the team solution is taken offline.
In addition, the team solution can also implement NTFS permissions on the team Web site. This provides an additional layer of security. See the Windows NT documentation for more details.
The permissions and roles you define for your solution are preserved when you create a template based on it. The Team Template wizard provides the option of removing existing database users before storing the database in the template. If you do plan to make a template based on the team solution, make sure all permissions are applied to roles rather than to users, because the specific users of a solution may change from instance to instance.