Introduction

For certain applications customer forms are not the desired way to gather information. If you have another source of data, for example a contact manager database or mailing list, it can be imported into the database for the merchant interface to use.

The merchant side interface for the @-Manager is designed to view, manipulate and use the database tables via a web browser. The merchant is provided with a password protected admin that allows for viewing, searching, adding, editing, deleting, exporting and e-mailing to customers.

In between the customer and merchant side is a general database and e-mail engine. The database is the true glue of the system: customers input data, and merchants can use the data. One of the most common ways for the data to be used is the e-mail engine. The e-mail engine has many features to enhance customer communications such as bulk e-mail generation, mail merge (personalizes e-mails with data from database), subscribe/unsubscribe link management, and more.

There are three general application models for use of the @-Manager:
Form Processing - stores information submitted in an HTML form into a database and/or sends the submission by e-mail. The focus of Form Processing is to allow site visitors to submit information.

• Contact forms
• Online surveys/feedback
• Questions/comments forms

• Online newsletters
• Product specials/updates

• Direct e-mail marketing
• Press release distribution

One of the best features of the @-Manager is that it is capable of supporting any combination of the above application models at the same time. This is accomplished because the database and merchant admin can support multiple data tables. It is best to think of a table as a set of independent data that has its own application. For example, one table might support your online newsletter, while another questions from your site visitors.

Storing Data
The information from customer submissions is stored into flat file database tables. The types of data (fields) that are stored are specified in table definitions. A table definition use an entry for each field (piece of data) you want to capture. Each field entry has three tab delimited elements; label, parameter, and type. The label is simply what you want to call the field, i.e. Name, Email, Phone, etc.

Field parameters are used to maintain data integrity. One function of parameters is to identify a required field. If a field is defined as required a submission error will be generated if the field is left blank. The main function is to define the first field as a key or not. When the first field is defined as a key, the table is called a keyed table.

A keyed table requires each value in the key field to be unique. If a users tries to enter a new record with a value for the key field that already exists, the @-Manager will not insert a new record but will update the pre-existing record.

In general it is best to use keyed tables when you want only the most recent data and a non-keyed one when you want to store all entries. For example, a contact list should be keyed, probably on a person's e-mail. This way an e-mail will only exist once, otherwise you could send multiple e-mails to the same box when bulk mailing. An example of a good non-keyed database would be a comment form. You may want to let the same person submit more than one comment and keep them all without overwriting previous ones.

The final part of a table definition entry is the type. These are the types of data that the @-Manager currently supports.

• text - the most common type that allows a user to enter any type of alphanumeric text.
• textarea - the same as text but displays a multi-line text box on auto-generated forms
• email - Basically the same as text but it signifies to the e-mail engine that this is an email address for sending submission responses and bulk emails. It also does format verification to make sure entries fit the general xxx@xxx.xxx e-mail format. Note that at least one email field must exist in a table definition if you want to sent form submission or bulk generated emails.
• password - same as text except that the form fields display asterisks (*) to hide typed characters.
• lists - This creates a drop down list in a form. You can create list of anything; i.e. red, yellow, blue (Format - list|entry1:display1;entry2:display2 where entryX is the entry that get stored in the db and displayX is the item displayed in the form). Lists are a way to limit users to a select group of answers
• states - List of the U.S. states displayed in a drop down box.
• date - This type creates three dropdown lists, one for day, month, and year. (format - date|2001:1945 where the 4 digit numbers represent a valid range of years)
• boolean - This stores dual state data, Yes/No.

To view examples of each type of each field type open the sample.td file in the installation kit.

Admin Features
Once your tables are defined properly you have the basics of what you need to start using the @-Manager. There are some additional features that are important for you to know about. The following is a brief overview (the features are covered in more detail in the users manual) of some of the more important features you will need to plan your system.

Database Access - Via the merchant admin interface you can access the records in your database tables. The admin provides a table view (multiple records in a spreadsheet style view) and a detail view of a specific record. You can add new records and edit or delete existing records. You can even export your database to use in other programs such as Excel.

Database Searching - The admin provides for multiple database searching features. You can search for records by exact matches, partial matches, or upper and lower boundaries. Recursive searching (search within a search) is also supported.

Bulk Email Engine - The bulk email engine allows the admin to send emails to everyone in a selected group of addresses with just a few clicks.

Email Templates - When you generate e-mail with the @-Manager admin you can directly input the message into a textarea box or use a template file. It is often easier to make templates for long e-mails such as newsletters or when the same e-mail is sent out more than once, i.e. a welcome message. The e-mails that are sent when a customer submits a form are always generated from a template, one for the customer and one for the merchant. Note that templates can send plain text or HTML formatted e-mail.

Mail Merge - Any e-mail that is generated by the system can have data from a form or database record and other select data sources (i.e. time and date) merged with the literal text of the message. This allows you to personalize bulk e-mail from a single message. For example if you had a database you could send the same message to hundreds of people with one click and each would be personalized to their name in the database.

Update Links (Unsubscribe/Subscribe) - Update links are a special mail merge feature that embeds a link in an e-mail that when clicked by the reader will update specified data in their table record. The most common use of an update link is to provide a link for people to unsubscribe to a mailing list.

Admin Fields - These are database fields that can be added on-the-fly via the merchant admin instead of standard fields that must be defined manually in the table definition. Admin fields are not displayed on auto-generated customer forms. The are designed for the site administrator to track and make notes on the records in a database.

Bulk Update - The bulk update feature allows you to change the value in a field for a selected set of records at one time. This is very useful for tracking mailings. For example, if you send a promotion to all your Texas customers, you can use the bulk update to mark all those records as having received the mailing.

Example Applications
This discussion provides examples of how to set-up @-manager for a specific application. While you will want to read the section that most closely resembles what you want to do, it is recommended you review all the applications as they build on each other and you will gain invaluable tips and hints.

Comment/Question form
A comment or question form is a basic HTML form on a website for customers/visitors to leave messages. This is a fairly simple application of the @-Manager. You would not even have to set up a database table, you could just send the submitted information in an e-mail to the merchant (this is called 'formmail' or 'form to e-mail' processing). However, just sending an e-mail of the submission does not give you the full benefit of the @-Manager, so lets create a table definition to store the data we want.

Table Definition	Displayed Form
Email R email Name R text Message R textarea	Email: Name: Message:

If you wanted to make this a very simple table you could just have a 'Message' field. However, you will probably want to send a response back to the customer so it is good to ask for an e-mail address. It is also good to get the person's name so you know how to address them in the e-mail.

Armed with the customer's e-mail and name you might want to send an automated acknowledgement of their submission back to them. An acknowledgement e-mail submitted by 'John' might read like:

Dear John:

We have received your submission and will be responding in the next 24 to 48 hours.
Thank you

Note that John is embedded in the email via the data merge feature.

In the table definition it is important to notice the field parameters are all 'R'. This means they are required fields but there is no key (signified by a 'K') and thus the table is not a keyed table. By not keying the table a visitor can submit more than one comment with the same e-mail address and it will not write over any previous comment. The only real drawback to using a table this way is when bulk e-mailing you run a risk of sending the same e-mail multiple times to the same address. This can be prevented by careful searching and selection of recipients when bulk e-mailing.

Website Contact Form
A contact form allows you to keep up-to-date information on your customers. A contact form is configured similarly to a comment form. The main difference is that you will want to key the table so that you only have the most recent information. In our example we will use the e-mail field as the key. In virtually all @-Manager applications you will want to key the Email field. This way when you send bulk e-mail you are assured of only sending one e-mail to each address.

Table Definition	Displayed Form
Email K email Name R text Phone R text Company D text Sex D list| :Choose;M:Male;F:Female	Email: Name: Phone: Company: Sex: ChooseMaleFemale

Note that we have created a drop down list for the contact's sex. We could have just use a field type of 'Text' but there is no telling what kind of answers we would get; M, Male, Man, F,Female, Woman etc. By using a drop down list we assure that our database will have only M or F (the M and F before the colon is what is stored in the database, the Male and Female is what is displayed on the form for the customer to use).

This helps when we are trying to search. If we want to send e-mails to just the females in our list, we just search the Sex field for 'F'. It is a good idea to use drop down lists whenever you know the complete set of answers a customer might give, i.e. the list of U.S. states.

Opt-In Newsletter
An Opt-In newsletter provides customers a form to join a list for newsletter distribution. Often the mailing list database is very simple.

Simple Mailing List

Table Definition	Displayed Form
Email K email Subscribe R boolean	Email: Subscribe: Yes No

This is a very basic data set for an online newsletter application. Of course you need the e-mail to send out the newsletter. You would probably want to use a subscribe field to track if users are a current subscriber (remember a Boolean is Yes/No). This way when you send out the newsletter you would first search your database on the field Subscribe for a value of 'Y'.

You may not want your form to ask somebody if they want to subscribe. After all, if they are submitting their e-mail address, you can assume they want to subscribe. We do, however, want to keep the Subscribe field. Using a hidden field in a hard-coded form we can submit a value of 'Y' to the @-Manager without requiring the customer to input it.

A typical feature of many newsletters is for there to be a link for the recipient to unsubscribe it they choose. The @-Manager supports this via update links that can be embedded in any e-mail you send out. Update links are very powerful and can be used for much more then an unsubscribe link. Another application of an update link would be if you sent out a newsletter in HTML format, but some of your subscribers can only view plain text e-mails. You could set up another Boolean field called 'HTMLVersion' and send an update link that people could use to switch between the HTML and plain text versions.

The @-Manager can manage several e-mail offerings from one table. For example, you might offer a newsletter, and mailings on product updates and special offers. Just create a separate subscribe field for each offering.

Multi-Offering Mailing List

Table Definition	Displayed Form
Email K email Newsletter R boolean ProductUpdates R boolean SpecialOffers R boolean	Email: Newsletter: Yes No Product Updates: Yes No Special Offers: Yes No

When you want to mail a newsletter search for all customers who have a 'Y' for the Newsletter field, when doing a Product/Update mailing search for those that have a 'Y' for that field, and so on.

One more variation of the Newsletter application is to have a newsletter with an expiration date. In the above example it is assumed that the person will keep receiving the newsletter as long as it is available. With a time based subscription the recipient would need to renew their subscription on a periodic basis. The renewal could be because they are paying for the subscription and there is a fee involved. You should check periodically to make sure your readers still want the mailings.

When doing a time based subscription it is best to use date fields instead of Booleans to track if someone is a current subscriber.

Time Based Subscription Mailing List

Table Definition	Displayed Form
Email K email Expires R date|2001:2005	Email: Expires: Month 01 02 03 04 05 06 07 08 09 10 11 12 / Day 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 / Year 2001 2002 2003 2004 2005

When you want to do a newsletter-mailing, search for all records where the Expires date is greater than (boundary search) today's date. You also might want to create a renewal e-mail for customers to re-subscribe to your newsletter. If you wanted to send a renewal notice to subscriptions that will expire in 30 to 60 days just search for records that expire in 30 to 60 days.

In the real world you would not want to let the customer set their own expiration date as in the example above. You could hardcode the form to not include the expiration date and when they are verified the expiration date can be entered from the admin.

If you have any problems or questions feel free to visit our support forum:

Report Installation Problem