A field is the most important type of element in Relate.  Fields define most of the data storage, data validation, presentation and interaction rules

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.

There are many types of fields.  Each field type has its own unique settings.  However, many settings are common to all or most field types.  These settings are described here.  The type-specific settings are described in individual sub-articles for each field type.

Setting	Description
Name	The name of the field used on all Relate administration and configuration screens.
Label	The label of the field is seen when editing and viewing form entries.  If left blank, the field name is used as the label.
Report Label	The report label of the field is seen as the column header when the field is a display column of a query, report or multi-entry report.  If left blank, the field name is used as the report label.
Required	Indicates that people filling out entries of the form are required to complete this field before saving thier work.  This should never be used as an absolute guarentee that a field is complete as there are many ways to circumvent this requirement:  1. The user completing the form may not have permission to fill out this field, but have permission to other fields.  2. The form entry may be created by formula where required fields are not enforced.  3. The field may have been filled out, then cleared via formula.  4. The field may be hidden (and therefore not required) by grouping settings of another field.  5. This field may be hidden or view-only using the grouping-and-hiding options on this field.  6.  An entry may be created using an alternate layout that doesn't include this field.  7. This field may have become required after entries were created.  8. And finally, this field may not have existed at the time older entries were created.
Long Label	Checking this box alters the automatic layout of the form so the label is on its own line above the field.  The default layout places the label and field on the same line with the label on the left and field on the right.
Hint	The hint is a bit of text which is shown next to the label, usually in italic font, to assist the user in completing the field correctly.  Normally the hint is not shown when the field is read-only.
Popup hint	Selecting the popup hint option causes the hint to disappear from below the label and instead a question mark icon is shown to the right of the label.  Clicking the icon opens a popup window where the hint is shown.  This is useful for very lengthy hints that would otherwise disrupt the layout of the form.
Hint hiding	The two options are to hide the hint when the field is read-only or to show it regardless of whether the field is editable or not.  This is used when the hint assists the user in interpreting the data, not just in entering it.
Bundle options	The bundle options are described in more detail in the article specifially on bundles.
Format	This option is different for each type of field, but serves a common purpose.  This setting or group of settings determine how users interact with the field, what it looks like and what values are valid or invalid.
Grouping	A few types of fields support grouping.  These types are section header, merge-report, boolean, single-select and multi-select fields.  Grouping works quite differently for each type of field, but they all share a few common concepts.  Grouping causes a field's listing to be split into two or more parts in the list of fields of a form.  The fields of the form are then re-ordered to place other fields between the various parts of the grouping field.  The fields thus moved are then part of the group for that grouping field.  The grouping field then dynamically controls the visiblility of fields within its group using rules that differ for each type of grouping field.
Default Value	Many field types can have a default value.  The specific settings available to each field type are different, but the concept is identical.  The default value is applied when a new form entry is created and before it is edited by the user or formula that created the entry.  Default values are never applied when editing existing entries.  Also, default values are not appled to existing entries when a newly created field is added to a form.
Auto-copy	Each field can be enabled for auto-copy.  Form entries can be copied in a variety of ways depending on the auto-copy setting on the form, user actions and Relate Script formulas.  When a form entry is copied, not every field on the form is copied or even is capable of being copied.  Only those fields with the auto-copy option checked are copied.
Frozen	This option is available only to BlueStep client-care staff.  It make the field settings unalterable except by BlueStep staff.
Fixed Id	This option is available only to BlueStep client-care staff.  This is a numeric identifier that is used for attaching BlueStep platform logic to dynamic Relate fields.  By convention, positive numbers are reserved for use by the Java development team.  Negative numbers can be used for other purposes.
Lookup Properties	This option is currently available only to BlueStep client-care staff.  Like fixed ids it is used to attach BlueStep platform logic to dynamic Relate configuration.  However, unlike fixed ids, this setting is available on all Relate components and is available to standard Relate administrators on several types of elements where they might be useful to formula designers. Lookup properties are defined as a newline delimited list of key/value pairs where the key and value are separated by an equal sign.  White-space on a line IS a part of the key/value pair.  Most key/value pairs must be unique for a given component type across all of Relate (within a BlueStep client org).  However, if the key begins with an underbar, the key/value pair does not have to be unique.  Unique key/value pairs are designed to allow efficient lookup of an arbitrary component.  Non-unique key/value pairs are used to categorize components or store other meta-information.
Field Identifier	On the "Advance Options" tab, this setting is the identifier of the field within Relate Script formulas.  It must conform to Relate Script identifier rules: Only letters, numbers and underbars; can't begin with a number; no keywords.  Also, the identifier must be unique across all fields on the form.
Formula	A Relate Script formula that executes on a single form entry each time the entry is saved.  More detail can be found in the Relate Script documentation.
Field Locking and Hiding	A series of options on the "Advanced Options" tab that define when a field is locked/read-only, hidden or editable.  These settings work independent from, but in harmony with, permissions and field grouping which can also effect field visibility and locking.  The options are explained in sufficient detail on the actual field edit screen, so the instructions will not be repeated here.
Style Class	The final option on the "Advanced Options" tab allows one or more CSS style class to be applied to an editable field.  The class or classes defined here are applied to the actual HTML input, select or textarea element when the field is editable.  In addition to making possible stylistic enhancements, CSS classes are also useful for identifying fields in JavaScript.  Normally, Relate fields cannot be easily identified because they have complex, dynamic names that change from page to page.
Permissions	The permissions tab works much the same as elsewhere in the BlueStep platform.  However, there are some significant differences.  These differences are described in the topic on Forms.