If you want to take full advantage of the Access Workflow Designer core features, such as workflow and offline capabilities, you must design your user interface to interact with the solution database and Access Workflow Designer infrastructure.
When designing your user interface, consider the following issues:
You can also refer to the MSDN Library for additional information about designing a user interface and working with Web pages. For details about accessing the MSDN Library, see Finding Information.
A user must have Microsoft Office Developer Access Workflow Designer client components and either Microsoft Data Engine (MSDE) or SQL Server installed to use a team solution. MSDE or SQL Server is required to serve as the local data store when the user takes the solution offline.
The user who is logged on when the Access Workflow Designer client components are installed is the only user who will be able to take a team solution offline on that computer. When installing the components, a local version of the solution database infrastructure is created on the local computer. The SQL Server login permissions for this local database are established based on the logged-on user's credentials. Therefore, the person who will use the solution must be the user who is logged on during installation of the Access Workflow Designer Client components.
For example, if another user logs on and attempts to create a subscription to the team solution on the same computer, the solution will not work correctly. The synchronization process may complete successfully; however, when the second user tries to take the solution offline, it will not work, because the logged-on user does not have a login for the local database.
Be aware that your team solution may be required to provide a mechanism for users to install the required components. For more information about user configuration requirements, see Setting Up the End-User Client Computer.
As mentioned earlier, you can use any user interface for your team solution that can create a read/write connection to a SQL Server database. Some of the core features available in Access Workflow Designer, however, require Microsoft Internet Explorer 5 or later as the user-interface browser.
Internet Explorer 5 is required if you want to use offline features, because Access Workflow Designer uses Internet Explorer SQL Merge replication and some custom code to synchronize the offline and online versions of the team solution.
When a user first chooses to take the solution offline, Internet Explorer creates the offline database, replicates the data and SQL objects, and stores the SQL connection information for the offline database.
Note Access Workflow Designer provides enhancements to the standard SQL merge process to enforce security. The client-to-server replication updates the online database with offline changes. The offline change log is played back to the server through the workflow engine to preserve workflow integrity. The server-to-client replication uses the regular SQL merge process to guarantee security and integrity of data on the server.
There are a number of places where you can implement security for your team solution. For conceptual information, see Security Permissions Model.
Because Access Workflow Designer uses FrontPage Server extensions, when deploying to an existing Web site, solution owners must have FrontPage administrator permissions on the Web site.
For best results, you must turn off the Anonymous user account for the Web server.
When connecting to database from your Web pages, it is recommended you use views rather than tables. For example, in the Issue Tracking solution, the Web pages use IssuesView rather than the Issues table. For more information, see The Structure of the Issue Tracking Solution.
If you want to take advantage of Microsoft Windows NTŪ security features for data access and sharing while you are creating a team Web site, it is important to use the Windows NT File System (NTFS) partitioning on the server containing the Web site.
There are several reasons to consider using NTFS:
Note An ACL is a list of user accounts, user groups, and their privileges associated with a particular resource, such as a directory or file. For example, a file could have a list of user accounts and user groups that can access it and information about what level of access they are granted to the file, such as read, write, or execute. ACLs are another core feature of the Windows NT security model and make it possible for flexible and precise access control to resources on the hard disk. Each directory and file has its own ACL that defines who can do what and where. Each ACL even has an ACL that specifies who can view and change the ACL itself.
For more information about Windows NT security options, see Chapter 4, "Managing Shared Resources and Resource Security" in Microsoft Windows NT Server Concepts and Planning. For procedural information, see Windows NT Help.
To secure your data during replication through the Internet or to reduce the chance that sensitive replicated data can be intercepted, you should use encrypted connections. To learn more about using encrypted connections, search for "multiprotocol net-library" topics in SQL Server Books Online.