Relate forms and their fields are the basis for all other Relate elements.  From a high-level perspective a form is a definition for a set of data to be collected, stored and reported on.  It defines what types of data will be collected, what the names of the data elements will be, how the basic data entry screen will be presented to the user, what constitutes valid and invalid data values and some of the dynamic interactions that will aid the end user as they use the form. 

From the opposite perspective, at the lowest level, a Relate form is an Oracle database table.  The fields of the form define the data types of the columns.  Other form and field settings define the rules and features of the end-user interface.

Forms have a number of settings which are described below, plus bundle membership settings described elsewhere:

Setting	Description
Name	The name of the form used on all Relate administration and configuration screens.
Label	The label of the form is seen when editing and viewing form entries.  If left blank, the form name is used as the label.
Description	The description of the form.  The description is seen at the top of the page, right below the form name, when editing a form entry.
Folder Location	Determines which folder the form is located within.
Show in Record Navigation	There are two checkboxes for this setting, one for Connect sites and one for Relate and HQ.  Relate and HQ are generally used by staff members while Connect site are generally used by other groups of users.  If the checkbox is checked, then the form will be visible in record navigation.  If the box is not checked, then the form will not be accessible in record navigation.  For HQ/Relate users there is one additional way to access forms aside from normal record navigation.  In the bottom section of Relate navigation, titled "Work with this Record", is a link to "Change Record Category".  All forms which are attached to each category of the current record are show here by name (not label) and can be navigated to.
Show in "My Account"	If checked, the form will be shown in the navigation for "My Account" so the user can view the form for their own record.  This assumes, of course, that the current user's record is allowed to have the form (via record type and category settings) and that the current user has permission to view at least one field on the form.
Number of Entries	This setting determines if the form can have only one entry per record or multiple entries per record.  The setting become read-only once a formula of any variety references the form.
Copy Option	The copy option determines how the auto-copy feature works.  The setting on the form determines if auto-copy is done every time a new entry is created, only when specifically requested by the end-user or both.  The auto-copy feature is dormant unless the form is a multi-entry form and at least one field on the form has been selected to auto-copy.  The auto-copy feature must be turned on for each field that should be copied by editing the field and enabling the auto-copy feature for that field. If auto-copy is activated when creating a new entry, then the data in the fields marked for auto-copy is copied from the "first" existing entry into the new entry.  Which entry is "first" is determined by sorting existing entries by the first summary field and choosing the first in the list. Auto-copy may also be activated manually.  This is done when the end-user edits an existing entry and clicks the "Copy" button at the top of the edit screen.  In this case the data is copied from the designated entry to the new entry in every field selected for auto-copy.
Change History Behavior	This setting is read-only for nearly all users, even most BlueStep client care staff, because of the inherent danger in setting it wrong.  It may be set to three values:  1. Always Save Entry History:  This is the default setting.  Assuming change history is enabled for the organization, this setting causes all form entries of this form to keep a full history of changes.  2. Never Save Entry History:  This setting causes no change history information to be stored for the entries of this form.  It is normally only useful when ALL of the data on the form is derived from other sources (which do keep a history) and the form is filled out via formulas.  It can also be helpful when the form contains transient data that is created then auto-transfered to other forms where the fully history is kept.  3. Save History Until Entry Delete:  This is a rarely used setting for a very special case.  It is used when data is automatically pre-created in anticipation of a user completing the information, and once completed by the user it can never be deleted.  Only the pre-created data that is not completed by the user is ever deleted.  The pre-created data is derivative information which should have a full history in the source, and the change history may be discarded when the pre-created data is deleted before it is used and updated by the user. Changing this setting is a two step process:  first check the box indicating a change is to be made, then make the actual change.  For organizations storing health records, changing this setting incorrectly may violate laws (HIPAA in the U.S) requiring the retention of medical data.
Summary Fields	The summary fields are used in two places.  First, each record has a record summary which is automatically generated by the system (unless overridden via a merge-report).  The summary fields determine what data from each form entry will be shown on the record summary.  Secondly, for multi-entry forms, clicking on the form label in record navigation brings the user to a screen listing all existing entries.  The list of entries displays each entry using the summary fields.  The list of entries is sorted by the first summary field.  The entry-list screen can be overridden via a multi-entry report, however, as mentioned in the copy option settings: the first summary field is still used to sort entries for the auto-copy feature.

Form Permissions
Form permissions work quite a bit differently than permissions in other parts of the BlueStep platform.

• Proxy permissions -- Form permissions technically don't apply to the form itself.  For instance, no matter who you grant "Editor" permission to they will not be able to edit the form unless they are a Relate administrator.  Form permissions actually apply to the entries of the form.  Permissions cannot be change for individual entries of the form.  All form entries have the exact same permissions, recieved by proxy from the form the entry belongs to. 
• Creator permission -- Most data in BlueStep can automatically be edited by who ever first created the data.  This is not true of Relate form entries.  The "Author" permission grants permission to create an entry of a form (or fill it out for the first time for single entry forms).  But the user must have "Editor" permission to modify any data once the entry is created.  There is, however, a special security group "Relate Creator" which can be granted "Editor" permission which then restores the normal rule of being able to edit anything you created.
• Relate Self -- Relate self is a special security group which applies only when a user is editing their own record.  This security group also applies when an anonmous user is creating a Relate record using a wizard.  This is intended to enable users to create their own account using a sign-up wizard and view/edit their own account information from the "My Account" area.
• Field inheritance -- Fields inherit permission settings from the form they belong to in the normal fashion, but forms actually inherit permissions from their fields in certain special situations.  A user will have permission to view a form entry if they have permission to view at least one field on the form even if they do not have "Reader" permission to the form.  Likewise, a user may edit a form entry if they have permission to edit at least one field on the form even if they do not have "Editor" permission to the form.  However, a user must have "Author" permission to the form (not just one of the fields) in order to create a new entry.  Also, a user must have "Editor" permission to the form (not just a field on the form) to delete an existing entry.