Let's say that you're tasked to create a customized Discussion Template for the Quality Assurance Group, with some extra features and a common look and feel. Within the Quality Assurance Group, there are three subgroups: Software, Hardware, and Data Quality Assurance. Each subgroup wants a few fields customized for their particular group, but the overall design of each discussion database should be the same. Your first instinct may be to create a template for each group, so that they each get their customized fields -- but that means maintaining three templates that are basically the same. If you make a design change to one, then all three need to be updated! The design of these templates can quickly get out of sync. A better solution, given this scenario, would be to have one common template for this group.

Naming convention
The first step in this direction is to consider your audience and naming conventions. You know that you'll have to support three separate groups within QA, so you'll need to set up a naming convention so that the application will know which group this database is built for. Let's use "QA" for Quality Assurance and "Disc" for Discussion.

That should cover the topmost level. For each of the subgroups within QA, let's just use the first letter of the group: "S" for Software QA, "H" for Hardware QA, and "D" for Data QA. Given that, when you create new databases off of your customized discussion template, you'll need to follow this naming convention (you'll see why when we look at the code in the next section).

Table A shows how your databases should be named:

Let's look at the code
Now let's look at how to set up customized fields based upon the group name. Let's say that each group has its own main contact phone number that needs to be displayed by default on the forms. In the Contact_Phone_Number field, you'll have the following code: