Contacts:
All contacts are stored in a single database table. This means that contact information about your staff is stored in the same place as information about your submitters. What differentiates staff from submitters is their level of access to the administrative parts of the system. This is called their access level.

Submissions:
Submissions are the work submitted by contacts to be considered by the publication. Each submission has a record in the database that contains all of the information about the submitted file (the author, title, etc). This record is linked to the submission file, which is stored on the publication’s server. The submission file can be any file type. By default Submission Manager accepts the following file types: DOC, DOCX, PDF, RTF, TXT. You can customize the file types and sizes that Submission Manager accepts.

Actions:
Actions are records of processes created by a staff member on a submission. There are 4 types of actions:

Accept:	Accepting a submission for publication.
Withdraw:	Withdrawing a submission from consideration.
Forward:	Passing a submission from one staff member to another. The system is designed with 4 different types of forward actions. These are fully customizable.
Reject:	Rejecting a submission. The system is designed with 4 different types of rejects. These are fully customizable.

NULL:	Contacts with a null access level have no administrative access to the system. This level is designed for submitters. Contacts with a null access level can submit stories, and check on their account, but that is all. The default access level is null.
admin:	Contacts with Admin level access have complete administrative access to the system. They can configure exactly how the system works, and can change the system’s appearance. They can view all submissions and can perform all actions on them. Admin users can set and change the access levels of all contacts. Because admin users have the power to change all aspects of the system, only very trusted contacts should be given admin level access.
editor:	Editors have access to some administrative areas. They can view all submissions and can perform all actions on them. Editors can also change the access level of contacts who are not admins; however, they cannot make anyone an admin, nor can they demote an admin to another access level. Editors do not have access to the configuration areas. This level is designed for staff members who will assign submissions to other staff members.
active 1-5:	These are 5 customizable levels of access to the system. Admins and editors can use these levels to group staff members by the types of actions they are allowed to perform. For example: active 1 can be used for a group of readers who can forward a story to another reader, but not reject it or accept it. Active 2 can be used for readers who can reject stories, but not accept them. And active 3 can be used for readers who can perform all actions.
inactive:	This level is used for a contact that was formerly on staff, but no longer has access to the system. (for example: A former editor)
blocked:	Contacts who have been blocked entirely from using the system (for example: submitters who have abused the system)

Step 1: Database Connection
Submission Manager needs to be told how to connect to your mySQL database server. You will be asked for your mySQL host name, username, and password.

Step 2: Database Name
Submission Manager will ask you for the name of the database you intend to use to store Submission Manager data. This is the database you created prior to installation (submgr).

Step 3: Table Creation
Submission Manager will create the necessary tables in the database named in step 2. It will also enter default information into some of the tables.

Step 4: Admin Account Creation
Submission Manager will now ask you to set up one admin contact to configure the program. More staff accounts can be set up later. To create this admin user you will need to input the first name, last name, email address and password for this contact.

Step 5: Configuration
Admin Login: You will be asked to log in to the account you just created to configure the system.

	* = required field
system_online:	This option allows you to decide who has access to the system at any given time. Your choices are: all: This gives access to the system to everyone including staff and submitters. no submissions: This gives access to everyone (staff and submitters) however no submissions are accepted. This is designed for the times that you want staff to be able to read submissions and perform actions but when you do not want to receive any new submissions. This might be used if your reading period has ended, but you still have submissions on the system that need to be decided upon. admin only: This gives access to admin level users only.
offline_text:	This text will appear to anyone who visits Submission Manager when the system is offline. (HTML allowed)
instruction_text:	This text will appear on the home page above the submission form. (HTML allowed)
submission_text:	This is the text that is displayed in the browser immediately after a contact submits a document and is sent to the contact in their confirmation email.
redirect_url:	Submitters will be sent to this URL following a successful submission. If you are accepting payments for submissions, this URL should point to your payment gateway. Redirect URLs can be set globally here, or by genre in the genre configuration. If left blank, the default submission confirmation will be displayed.
test_mode:	Use this when testing the system. Administrators can test different actions, but no emails will be sent to contacts. When you are working in test mode, the phrase “test mode” will appear in brackets above the name of your publication.
timezone:	Choose your local time zone. All dates and times are stored in the database as GMT, but this setting controls how users see these dates and times.
dst:	Check this box if Daylight Saving Time is used in your locale. Submission Manager uses your web server’s interpretation of daylight savings time (DST). This means that if your web server is in a locale that recognizes DST differently than your locale, your times may be off by one hour during DST.
* company_name:	Fill in your company name here.
show_company_name:	Checking this will display your company name (as listed above) in the upper left corner of the screen on all pages of Submission Manager.
logo_path:	Fill in the server path to your company’s logo graphic (.gif or .jpeg) for it to appear in the upper left hand corner. The logo can appear in addition to the company name or instead of the company name.
* app_url:	The absolute URL to your installation of Submission Manager. (https://www.example.com/submissions).
fonts:	A comma separated list of fonts to use. Browsers will use the first font available on a user’s computer.
font_size:	Base font size. Other fonts will be larger/smaller relative to the base.
color_background:	The color of the background of the page. The default for this area is white.
color_foreground:	The color of the area around the forms. The default for this is a light grey.
color_form:	The color that appears inside of the form fields. The default for this is a darker grey.
color_text:	The color of the text.
color_link:	The color of text that is a link.
color_link_hover:	The color that link text will change to if a user hovers their mouse over that link text.
border_radius:	Rounding of borders (in pixels).
submission_limit:	This is the number of outstanding submissions you would like any individual contact to be able to have on the system at once. The default is 3. Setting this to 0 will allow an unlimited number of submissions. Submission limits can also set by genre in the genre configuration.
pagination_limit:	This determines how many records per page are displayed when the staff is reviewing submission and contact records. A setting of 0 means no limit.
default_sort_order:	This determines default sorting of submissions. The default is date ascending.
* upload_path:	Fill in the absolute server path to the directory where you want all of your submission files to be stored. For security reasons, it is strongly suggested that this be a non-public directory, stored somewhere outside of your server’s document root. Files will be stored in this directory in sub-directories by year. This directory must be readable and writable by your web server.
* general_dnr_email:	All automatically generated email notifications (both submission confirmations and non-personal rejections) will come from this address.
* admin_email:	The main system administrative email address. The system will display this to submitters if there is a system error. This should be the email address of your web master or of someone familiar with the system setup.
mail_method:	The method by which mail notifications will be sent (options: mail, sendmail, smtp).
smtp_secure:	Set SMTP security protocol (options: SSL, TLS).
smtp_port:	SMTP port number (if using SMTP authentication)
smtp_auth:	Check this if you SMTP server required authentication.
smtp_host:	SMTP host name (if using SMTP authentication)
smtp_username:	SMTP username (if using SMTP authentication)
smtp_password:	SMTP password (if using SMTP authentication)
submission_price:	Price charged for submissions. Price can be set globally here, or by genre in the genre configuration.
currency_symbol:	The symbol displayed in front of all prices
success_result_code:	The result code returned by your payment gateway indicating a successful transaction.
payment_redirect_method:	This determines by which method payment variables will be sent to the payment gateway. The default is GET, however some payment gateways require POST or cURL.
cc_exp_date_format:	credit card expiration date format
captcha_version:	Google reCAPTCHA version (to prevent robot submissions)
captcha_site_key:	Google reCAPTCHA site key (to prevent robot submissions)
captcha_secret_key:	Google reCAPTCHA secret key (to prevent robot submissions)
mysqldump_path:	Path to the mysqldump program to make database backups
csp:	Content Security Policy
exclude_countries:	comma separated list of excluded country codes (use "USA_only" to exclude all but USA)
send_mail_staff:	If this box is checked, the system will send email notifications of all submissions and all actions to selected staff members. Whether or not a staff member receives these emails is determined in their record in the contacts area.
send_mail_contact:	When this is checked, a submitter will receive a submission confirmation email.
allow_withdraw:	When this is checked, submitters will have the option of withdrawing their own submissions from consideration. Submitters will only be able to withdraw submissions that have a status of “received”.
show_date_paid:	When this is checked, the “date paid” column will be visible in all submission displays. Unpaid submissions will display with a red border.
show_payment_fields:	show credit card fields on submission forms
check_updates:	check for new versions of Submission Manager

If you need to reinstall Submission Manager:
If you are reinstalling Submission Manager for any reason, know that it will overwrite existing tables with the same name, and all data will be lost. Be sure to backup any data before reinstalling the program.

If your mySQL configuration changes after you have installed Submission Manager:
If your mySQL configuration changes after your have installed the Submission Manager, you can update your mySQL connection parameters by editing the file config_db.php located in the directory where you installed the application. The config_db.php is a plain text file which looks like this:

<?php
$config_db = array(
'host' => '[host]',
'username' => '[username]',
'password' => '[password]',
'name' => '[name]',
'port' => '[port]'
);

define('INSTALLED', true);
?>

Update the [host], [username], [password], [name], and [port] to match your mySQL connection parameters. The [name] field is the name of the database where you are storing Submission Manager data. Be sure to use a plain ASCII text editor when editing this file. When you have finished editing the file upload it to your web server in the directory where you installed Submission Manager.

The submission area is where submission management takes place. Admins and editors can see all submissions on the system from this window.

When admins or editors first log into their account, they will be taken to the submission area, which will be blank. Admins and editors must always select the submissions they wish to see.

To do this they should use the form on the upper left hand corner.

Searching by keywords: Staff members can search by any word or phrase that appears in the submission ID#, submitter ID#, submitter name, submission title, comments that the submitter left when submitting and notes that staff members left for submissions. Enter one or more keywords in this box. To search for an exact phrase enclose the phrase in double quotes (for example: “Good Morning”). To search for a specific submission ID# then prefix the number with “id:” (for example: id:123).

Filtering by other criteria: Staff members can search by specifc criteria based on genre and by the last action performed on a submission.

genre:	This field allows staff to filter submissions by genre. A staff member can choose to look at all submissions, or can look at submissions of only one genre.
last action:	This field allows the staff to further filter submissions by the last action performed on them. To see all unforwarded submissions, a user should select “no action”.
to:	This field allows staff members to further filter the records by whom a submission was last forwarded to (this is the staff member who currently has the submission in their queue). This field is active only when the “last action” field is set to any of the forwards.
sort:	This field allows the staff to sort the selected records by date in either ascending or descending order.
paid only:	When checked, search results will only include submissions where the “date paid” field is filled in. This check box is only visible when “show_date_paid” is checked in the General Configuration.

These four fields are designed to logically allow a staff member to find any group of submission records on the system.

Example 1: A staff member is looking for poetry submissions that were last forwarded to staff member Mary Smith using Forward 1:

find keywords:	(leave blank)
genre:	all poetry
last action:	forward 1
to:	Smith, Mary

Example 2: A staff member is looking for all unforwarded submissions:

find keywords:	(leave blank)
genre:	all submissions
last action:	no action

The selected submissions will be listed in a table along with the following information:

ID#:	The unique number of the submission assigned by the system
date / time:	The exact time the submission was entered
date paid:	The date that the submission was paid. This column is only visible when “show_date_paid” is checked in the General Configuration.
writer:	The name of the writer. If the name of the writer appears in red, it means that the writer name is different from the contact name. This indicates a submission that has come from a writer using a pseudonym, or a submission that has come from an agent. Hovering over the writer’s name will reveal their email address and name and address if available. Clicking on the writers name will show all submissions by that writer.
title(s):	The title (or titles) of the submission
genre:	The type of submission (the system defaults are poetry, fiction, nonfiction, other. These can be changed in the genre configuration area)
file:	A link to the submitted file. The name of the file will be the unique id number, followed by the document extension. Clicking on this link will prompt the staff member to either open or save the document.
comments (by submitter):	If the writer has submitted comments, the word “view” will be present. Hovering over the word view will show these comments. Clicking on the word view will open the comments in a popup window.
notes (by staff):	Notes by the staff made about the submission, not about the contact. Hovering over the word view will show these comments. Clicking on the word view will open the note in a popup window.
status:	The current status of the submission. System defaults can be used or it can be customized by action type. The default status levels are as follows: Accepted: For all accepted submissions. Declined: For all rejected submissions. Withdrawn: For all withdrawn submissions. Received: For all other submissions. For information on customizing this field, click here.
actions:	The number of actions that have been taken on a submission. Clicking on this number allows the staff member to view the action list of that submission.
tag:	Admins and editors can use this to perform the same action on multiple submissions.

Viewing a submission:
To view a submission, the staff member should click on the file name. Depending on how their browser is configured, the submission will either appear in the user’s browser window, or they will be prompted to save the document to their computer.

Performing one action on one submission:
To perform an action on one submission, a staff member should click on either the submission ID # or the number in the action column. All actions that have been created for this submission will now be displayed.

To create a new action, the staff member should click on “insert new action”. The create action form will be displayed.

Let’s say they are forwarding this story to a reader.

• They will fill in the action type (forward 1).
• Then select which staff member they would like to forward the submission to.
• They will also have the option of making notes about the action (in the notes box.). These notes are only for the staff to see.
• They can fill in a message that will be sent in the email to the receiver.
• Once they think they have the action as they want it, they should click preview. All of the details of the action will be displayed in the preview area to the right of the form.
• If the action is correct, they can click send and the action will be created.

Accepts, withdrawals, and rejects work in the same way, but for these actions the “to” field will be grayed out.

Performing one action on many submissions:
Admins and editors can also perform the same action on multiple submissions. To do this, the staff member should click the tag box for all submissions on which they want to perform the same action.

Using the action box on the upper right hand corner, the staff member can select the action type, and for forwards, the receiver.

Clicking on “apply to tagged” will bring up a confirmation page that lists the action type, the receiver, and all of the submissions that will have this action performed on them. Hovering over the action name will display the email text that will be sent to the receiver(s). If everything looks correct, the staff member should hit confirm and the actions will be created.

Access to this area by Staff Members with Access Levels 1-5:
Staff members with access levels 1-5 can perform actions as described above with 3 exceptions:

1. They can only see submissions forwarded to them and any other submissions made by a submitter in their assigned list.
2. They can only perform the actions allowed by their access level.
3. They can only perform one action at a time. (The tag field will not be visible to them).

This area is accessible to admins and editors only. When an administrator or editor first enters the contact area, the contact list will be empty. Just like in the submission area, staff members must select the records they are interested in seeing.

To do this a staff member should use the fields on the upper left hand corner.

The first field allows staff members to select which type of contacts they would like to see. They can choose “any contact” (which will show contacts with all access levels), “any non-staff” which will show contacts that have a null access level, “any staff” which will show all contacts with any access level other than null, or they can choose to see contacts of a specific access level.

The staff member can choose to further narrow their search by using the next two fields. They should then choose which field they would like to look at (i.e. lastname) and then fill in the information they are looking for in the box below. The user can search for fields that either contain the text that they typed or that are an exact match for the text that they type. If they are searching for fields that contain some specific text, they should use % as wildcards.

Example 1: If the staff member is looking for a contact whose email address they know is joe@example.com, they will select:

show me:	any contact
whose:	email
equals:	joe@example.com

Example 2: If the staff member is looking for all submitters who have an email address from Gmail, they will select:

show me:	any non-staff
whose:	email
contains:	%@gmail.com

Example 3: If the staff member is looking for other staff members whose last name begins with b, they would select:

show me:	any staff
whose:	last name
contains:	B%

To see all contacts, the staff member should search for any contact and leave the field empty.

When the search is complete a list will be displayed of contacts matching the search criteria. The list will contain the contact’s unique id number, their name, email (a mailto link), and access level. The list will be sorted by whatever field the staff member chose to search by in ascending order.

Hovering over the contact’s name will show you that contact’s name, email address, and full mailing address.

Seeing a complete contact record, editing or deleting a contact:

To see or edit a contact record, a staff member should click on the name or the contact id. The chosen contact will be displayed in full on the right hand side. The staff member will now be able to see and edit the contact’s password, their access level, whether or not they receive administrative emails, notes about them, and how many submissions they have on the system.

Editing basic information: To edit a contact’s name and address information, the staff member should simply type the new information over the old and hit update. Old information will not be saved. To keep older information, use the notes box.

Setting the access level of a contact: The access level of a contact is set in the access level field. Admins can change the access level of all contacts. Editors can change the access levels of contacts who are not admins. Editors cannot create an admin level contact, nor can they delete or demote them. To change an access level, the staff member can simply select the new access level and hit update.

Deciding whether or not a staff member receives system notification emails: The contact form also contains two checkboxes that determine whether or not a staff member will receive notification of each submission and action entered into the system. These checkboxes will not be active for contacts with a null access level.

Deleting a contact: The delete button will delete a contact from the system. When a staff member deletes a contact, they will be asked whether or not they also want to delete any submissions or actions related to this contact.

Adding staff members to the system:

Admin level users and editors can add contacts to the table and assign their access level. This is done by clicking on “insert a new contact” and filling in the form.

The minimum amount of information needed to create a staff contact is first name, last name, email and password.

To create staff members, the admin or editor must select an access level of 1-5, admin, or editor. Access Levels are described in the overview section of this document. Editors cannot create an admin level user.

Before testing the system you should create a few staff accounts.

Submission Manager comes with 6 standard reports. These are designed to give admins and editors an overview of the data on the system. The reports are:

daily report:	This report shows all submissions and actions that were entered on a given day. By default, the “date” field is pre-populated with the current date. To see a daily report on a different date simply enter the date in the “date” field using the YYYY-MM-DD format and click show report.
submissions by month:	This report shows a count of all submissions by genre by month.
submissions by status:	This report shows a count of all submissions by their current status. Clicking on any count will show a complete list of all of the submissions that make up this count.
actions by staff:	This report shows a count of all actions entered by each staff member. Counts are broken down by action type. In this report, staff members are sorted first by access level, and then by last name.
forwards by staff:	This report shows a count of submissions that are forwarded to each staff member. Counts are broken down by genre and by the type of forward. In this report, staff members are sorted first by access level, and then by last name. Clicking on any count will show a complete list of all of the submissions that make up this count.
contacts by access:	This report shows a count of all contacts broken down by access level. Clicking on any count will show a complete list of all of the contacts that make up this count.

This area is used to configure Submission Manager for your publication. It is accessible only to admins.

General Configuration: This page allows the administrator to adjust the configuration of the system, as described in the configuration options section of this document.

Action Types: This is where the administrator will customize the actions. The system is designed with 10 action types. All 10 action types are customizable. For the system to work you do not need to use all 10 action types.

accept:	Use this to accept a submission for publication.
withdraw:	Use this to withdraw a submission from consideration.
forward 1 - 4:	Use these to forward a submission to someone else on your staff. More information about configuring forwards can be found in the “Configuring the system for your publication” section.
reject 1 - 4:	Use these to reject a submission. Publications can use these four levels of rejects to create standard rejection notices that range from more to less encouraging. Rejections can be configured to be form letters, or to allow room for personal comments.

All actions have a list of variables: some that are configurable, and some that are hard coded. The variables are as follows:

action type ID:	This is hardcoded and used by the system to identify the action.
action name:	This is hardcoded and used by the system to identify the action.
description:	A 10-character field to describe the action to your staff. for example: Reject1 can be described as “standard”, reject 2 as “nice”, reject 3 as “very nice” and reject 4 as “personal”.
status:	A field that will control what is displayed as the status of submissions. When this is null, the default status (Accepted, Declined, Withdrawn, Received) will appear. When filled in, this field will appear in the status column seen by both editors and submitters.
active:	When this box is checked this action will be active on your system. If you only want to have one type of rejection, you would deselect the active box on rejects 2-4.
access groups:	Use this field to decide which access groups can perform this action. For instance, if you have decided that readers in access group 3 will have the power to reject stories, you will select group 3 for all levels of reject. If readers in access group 2 cannot reject, deselect group 2 for all rejections.
email from reader:	If you check this box, the email will have the return address of the staff member that created this action instead of the general DNR email address. This means that if the submitter hits reply to this email, the staff member who created the action will get the reply. This option should be used sparingly. If it is not checked, the email will be from the email address chosen in the “general dnr email” field in the configuration area.
email subject:	This is the template for the subject line of the email that will be sent to the receiver when this action is performed.
email body:	This is the template for the body of the email that will be sent to the receiver when the action is performed. Note: When creating the email subject and body you can use placeholders to fill in information contained in the database. (for example: the name of the submitter or submission). A legend explaining the placeholders is on the left side of the page. For example, if you would like the title of the submitted story to appear in the email that is sent with any given action, you can simply type “[title]” where you want the title to appear in the text.

File Types: Submission Manager is preconfigured to only accept file types with the following extensions: DOC, DOCX, PDF, RTF, TXT. Submission Manager will only upload files that have a valid file extension. Admins can add/delete/update file types using this configuration page.

Fields: The fields on the Submission Manager main forms can be configured here. Admin users can set the following form field properties:

Name:	The display name (label) of the field.
Default Value:	The default field value. This can be used to set the default country (USA for example) and the default state of the mailing list checkbox (checked or unchecked).
Max Length:	The maximum length that the field will accept. This can used to enforce limits on field lengths (for example: 3000 characters for the comments field).
Enabled:	Whether or not a field is present on the form (disable unneeded fields).
Required:	Whether or not a field is required. Submitters can be forced to fill out specific fields.

Groups: Submission Manager comes preconfigured with 7 staff groups: admin, editor, and active 1-5. This page allows admins to set which groups can forward submissions to which others groups. Admins can also flag certain groups as “blind” which means any member of that group will not be able to see the contact info for submitters.

Genres: Submission Manager comes preconfigured with 3 genres: poetry, fiction, and nonfiction, but you can add as many genres as you like. Genres can have their own price, submission limit, and redirect URL. If you choose to set any of these variables here, your genre settings will override the settings on the General Configuration page. To add new genres, type the genre name in the new field and click update. Genres have the following variables:

Genre ID:	Unique numeric indentifier for each genre.
Name:	The name of the genre.
Submission Limit:	The number of times that each submitter can submit using this genre. This limit overides the global limit set in the General Configuration. Set to 0 for no limit.
Redirect URL:	Submitters will be sent to this URL following a successful submission. If you are collecting payments for this genre, this URL should point to your payment gateway.
Price:	Price for submissions to this genre. This limit overides the global price set in the General Configuration.
Active:	When unchecked this genre will no longer be available for submissions.
Blind:	When checked submissions in this genre will have hidden submitter contact info so the staff cannot see who is submitting.

If you turn off genres on the General Configuration page, this area will still appear, but will not affect how the system runs.

Payment Variables: Submission Manager can collect payment data and send it off to your payment gateway following each submission. To do this, you will need to tell Submission Manager which variables your payment gateway requires that you send to it, and which variables they will return. This configuration area allows you to control this process. We highly recommend that you have an experience programmer manage this part of the installation. When you first install Submission Manager, no payment variables will be set.

Outgoing Payment Variables: These are the variables that are sent to your payment gateway. Consult your payment gateway documentation to determine which variables are required to process payments. Some will be constant (like the login of your payment account) and some will taken from the submitter data (like the submitter’s name and credit card information). In the name field, type the Name of the variable required by your payment gateway. In the value field, type the data Submission Manager should send. If the information is static, simply type the information in. For example, if your login for the payment gateway is “Example”, Simply type “Example” in the value field. If the information needs to come from submitter data, you may use the local variables shown at left. For example, If you need to send the price, type $price in the value field. Variables that come from submitter data should be preceded by the dollar sign ($).

Incoming Payment Variables: These are the variables your payment gateway returns. Submission Manager requires two return variables.

1. $submission_id: Each submission is assigned a unique numeric identifier known as submission_id. In order to update a submission as paid, your payment gateway must return this submission_id.
2. $result_code: This lets submission manager know if the payment was successful. It will be one or more characters and is payment gateway specific.

Submission Manager does not store the result code for each record, it uses the result code to update the date paid field in the submission record.

The maintenance area contains processes for managing system data. It is accessible only to admins.

Cleanup Temp Files:
Typically there is a one to one relationship between database submission records and uploaded files.

Due to lost connections and server glitches there are sometimes submission records without a corresponding submission file and submission files without a corresponding record. We’ll call these orphaned records and files.

The Cleanup Temp files function allows you to delete these orphaned files from your system. Selecting cleanup temp files will produce a table that lists a complete count of records and files by year, and shows all unrecorded files (files without matching database records) and missing files (database records without matching files).

Clicking on the name of an unrecorded file will display the file that is missing its record. Clicking on a missing file will show the submission record that is missing its corresponding file. You can delete orphaned files by clicking delete temp files.

Important Note: Temp files are always created during the submission process. They are created as soon as a submitter selects the file from their computer and retains the temporary name until the submission is complete. It is therefore safest to make sure that all temp files that you delete are at least a few hours old.

Sample Data:
In order to test the system you’ll need a set of dummy submissions to work with. Clicking insert sample data will create 100 dummy contacts, submissions and files to test the system. Clicking delete sample data will delete all of those dummy records. All sample contact records will have an email with the domain name of @example.com. (for example: sally123@example.com).

Export Data:
This function will allow you to export the contact data to a .csv file. This format is easily read by other database applications.

When exporting data you have four options:

include primary key field:	When this is checked, the Submission Manager contact id will be included in the export.
include staff contacts:	When this is checked, staff contacts will be included in the export.
insert field names as first row:	When this is checked, the first row of the export will be the names of the fields.
use CLMP data structure:	When this is checked, the field names will be the same as the field names in the CLMP fulfillment template. This will make it easier to merge these records for mailing or other uses. We do not, however, recommend you import this data into the current CLMP fulfillment template.

You can select the records to be exported in three ways. You can use a range of primary keys (the default is to select all records), you can select all records created after a certain date, or you can select all records modified after a certain date.

Backup Data:
This function will backup your Submission Manager mySQL database using mysqldump. The server path to mysqldump can be set in General Configuration using the mysqldump_path setting. By default this is set to simply mysqldump which assumes that the program is in your server’s PATH configuration. You may have to set an explicit path, such as /usr/local/mysql/bin/mysqldump for example.

Purge Data:
This function will purge submissions and their related actions and files. You can choose a range of submissions based on dates.

WARNING: This will permanently delete data from your database! Please backup and archive your database before using.

Test Mail:
This function will help diagnose mail delivery problems.

Test Upload:
This function will help diagnose file upload problems.

Update Data Structure:
This function has been put into place to allow administrators to easily update Submission Manager when future versions become available. Detailed instructions for using this function will be sent with any new versions of Submission Manager.

Versions:
This will show the versions of your installed Submission Manager, the latest version of Submission Manager, PHP, and mySQL.