Mail notification can be made much more flexible with the use of a configuration document, too. I have a simple Help Desk application, configurable by group and severity level, that gives administrators the choice of setting up help ticket notification email to go to individuals or groups. As you can see below in Figure A, the administrator can go in and set up a notification group and choose whether to notify the whole group automatically when a ticket is assigned or a specific person for group assignments.

FIGURE A


Mail notification can be easily configured for added flexibility with the addition of a configuration record such as this and few extra lines of codes. Roll over picture for a larger image.

The administrator can also decide, for groups with a specific person indicated, whether that mail should change and go to the whole group for high priority tickets. Each group can decide how they want tickets assigned to them to be handled, making everyone much happier. And it only adds a few lines to the notification code! Then, when there's a problem or a change that needs to be made, the users call the database administrator, not the programmer. This makes me much happier!

Configuration control
One of the first things you must do as the developer is decide how the user administering the application is going to do it. Whether through a special view, a profile document, a dashboard dialog, a data dictionary (usually another database), etc., you'll need to pick one method for administration. My preferred method, for simplicity and flexibility, is a view, or set of views, and forms specifically designed for the task.

I usually also add a view called Admin\Configuration to present any configuration documents and administration functions. Since it's consistent across most of the applications we've built in the company, users have an easier time figuring out where to look, as do we.

In setting the selection formula for this view, I once again have consistency working for me. I try to always start the name of the forms I use for configuration with the word System. All the other forms I name SELECT, with @begins(Form;"System") as my view formula. In Figure B, you can see my Configuration view in a simple application.

FIGURE B


This Configuration view shows some of the functions (view buttons) and configuration lists for this application. Roll over picture for a larger image.

Since this view is going to be access-controlled to prevent unauthorized users from getting in and making changes, I also added a hidden view, usually called ($Lookups) with an alias of Lookups, so that calls looking for configuration information have a consistent place to go. Notice in Figure C that I also have other hidden lookup views which I'm using for the presentation of more detailed configuration information. (If you hold Ctrl-Shift while opening a database, you'll be able to see the hidden views.)

FIGURE C


There are many visible as well as hidden lookup views for these application configuration documents. Roll over picture for a larger image.

You'll also need to decide how you're going to control access to the application's configuration. My preferred method is to create a database role that I usually call something like SystemAdmin. This role's used for access to the configuration views and the configuration forms. Depending on the application, and the way the application's control is broken up among the user population, you may want to use several roles to control access to different parts of the configuration. What you call the role doesn't really matter, though consistency will help in the long run.