There are three security categories for Access Workflow Designer users:
Each of these roles is associated with specific team solutions responsibilities and the necessary permissions in Windows NT, SQL Server, Microsoft FrontPageŽ, and the team solution that make it possible for them to carry out those responsibilities. In some cases, the duties of the server administrator and the team solution owner may overlap. For more information, see User Responsibilities by Category and User Permissions later in this topic.
The team solution server administrator is typically responsible for the following activities:
The team solution developer must be a member of the modAppOwner group. This role is typically responsible for the following activities:
A user who accesses the team solution through a client browser has few responsibilities requiring special permissions. Instead, the team solution user is typically assigned to a Windows NT group domain account associated with a database role. The user's privileges when using the solution depend on the role to which the user belongs.
Note It is recommended you use group accounts to simplify server administration.
The permissions associated with these categories of user are as follows:
| User | Windows NT account | SQL Server role | FrontPage permissions |
| Server administrator |
System administrator |
Sysadmin
dbo in modSystem database |
System administrator |
| Team solution owner |
modAppOwner group |
modAppOwner database role
dbo for the team solutions they create db_owner permissions (required to register existing SQL Server databases as team solutions) |
FrontPage administrator group |
| Team solution user |
User or group account |
SQL user or group login associated with Windows NT accounts | none |
When Access Workflow Designer server components are installed, setup creates a Windows NT group called modAppOwners and sets all necessary Distributed Component Object Model (DCOM) permissions that make it possible for members of modAppOwners to create team solutions.
Setup also creates a SQL Server login for the Windows NT modAppOwners group called <servername>\modAppOwners. This login is added to the database creators (db_creator) role on the server and db_user on the master and modSystem databases. These permissions make it possible for solution owners to create team solutions based on templates, create new SQL Server databases, and register team solutions.
The modAppOwners Windows NT group is also added to the FrontPage Administrator group, so members can create Web sites for team solutions.
To grant a developer the appropriate permissions, the server administrator must add the developer to the Windows NT modAppOwners group using the Windows NT Server User Manager.
If the developer wants to register an existing database as a team solution, then the administrator must make developer a database owner (db_owner) on this database. The person who creates a database is automatically the db_owner.
In addition, if the members of the modAppOwners group typically will be performing administrative tasks such as creating new SQL Server logins, the server administrator should grant the modAppOwners group system administrator privileges on the SQL Server. This is not the default.
For details, see Creating Windows NT User and Group Accounts.
As a member of the modAppOwners group, the team solution developer can create SQL Server roles appropriate for a team solution, add solution users or groups to these roles, and set permissions on these roles as required by the team solution. To create the roles, there must be existing SQL Server logins and Windows NT accounts.
When developing the solution, modAppOwner members can set permissions for workflow actions within the Access Workflow Designer. For details, see "Controlling Permissions for an Action" in the Access Workflow Designer Developer's Guide.
Row-level permissions can be set using stored procedures that are available in the Issue Tracking template: modGrantRowPermissions, modDropRowPermissions, modEnumRowPermissions. See the Issue Tracking solution for an example of how to handle row-level permissions using these stored procedures. For information about implementing row-level permissions, see "Setting Row-Level Permissions" in the Access Workflow Designer Developer's Guide.
If row-level permissions are enabled in the team solution, users can specify permissions for individual issues based on solution roles. If an issue is assigned to a user, that user can select specific roles to have read-only or write permissions for the issue.