A Relate custom application is a collection of elements or components.  These elements are created, configured and connected to one another via the Relate site.  Some of these elements can be connected to webpages on the other websites throughout the system.  These external connections are configured on the individual websites.  Below is a list of Relate element types.  The next article in this series describes potential external connections to Relate.  Listed with each is a brief description of the function and capabilities of that element.

Important concept:  Most types of Relate configuration elements have both a name and a label.  The name is required, but the label is optional.  The name is what the element is called for the Relate configuration person and is shown on all configuration screens.  The label is what the element is called when the end user sees it.  The label is shown while entering data and viewing reports.  If no label is given, then the name is seen both on configuration screens and on end-user screens.  During advanced scripting logic some items need to be looked up by name.  The name can be set and never changed since only the configuration staff will ever see it.  This allows for reliable look-up by name.  The label, on the other hand, can change based on the whims of whoever is in charge and their preferences at the moment without breaking any scripting logic.

Record Types and Categories
These elements were discussed in the previous article.  They allow forms and form entries to be associated with Relate records.  Each record type has exactly one private form that is unique to that record type and contains, at minimum, a field representing the name of the record.  All other forms in the system can be connected to as many record types and categories as the designer wishes.

Bundles
Bundles allow all of the other types of Relate elements to be grouped together into projects or bundles.  This provides numerous benefits for large scale Relate configurations such as:  1. Gathering components which may be spread across many areas of Relate into a common place where their relationships to each other can be recorded and described. 2. Providing version notes so changes over time can be described and reviewed.  3. Finding and highlighting changes that have occurred since a specific timestamp.  4.  Locking elements from unauthorized modification and requiring note taking when authorized users make changes.

Forms and Fields
As discussed a form is a collection of fields.  Each field has a data type such as text, number or date.  Each field also has a name that identifies the bits of data that will be entered using the form.  The fields are the core of any Relate application.  Because of this, each field has numerous settings which allow its appearance and behavior to be adapted to a wide range of uses.   The system will automatically generate a default view of the form, based on the field settings, which allows the form to be filled out and an entry created.   Remember, however, that a form never stands alone.  Until the form is associated with one or more record types and/or record categories it is entirely useless.  Below is a quick list of the types of data that can be configured and entered via a field element.

• Text - Text with a maximum length of 4000 characters.  The text may be formatted in various ways such as a phone number, a U.S. state abbreviation, an email address, etc.  Text fields can also present a list of choices to select from, and the chosen text is stored in the field.  Text fields can also be used to select-by-searching from some very large pre-defined lists such as the list of all medications licensed by the FDA.
• Memo - Multiple lines of text.  This can also be used to store a chunk of HTML or a list of email addresses (but nobody ever does that...I'm not sure why).
• Date/Time - Stores a date, a time or both.  Dates and times stored separately are always displayed as entered, but fields storing both date and time are converted to the current user's preferred timezone whenever they are displayed or edited.
• Number - Stores a number in the mathematical sense (never a phone number or social security number).  Integers, real numbers or currency values can be stored.  Currency values are just a real number with two decimal places.  They don't do currency conversions or track what currency is being stored.
• Boolean - Boolean is the mathematical term for things with only two possible values.  Boolean fields store true/false, yes/no, paper/plastic or any number of other simple one-or-the-other choices.
• Single Select - This type of field displays a list of choices and allows exactly one to be selected.  The list of possible values is configured via an option list.  The field stores a reference to the option in the option list, not the actual text of the option.  Because of this, changing the label of an option changes how that option will be displayed in every form entry where it has been selected throughout the system.
• Multi-Select - Nearly identical to a single select field except multiple options can be selected.  I bet you figured that out before you finished the sentence.
• Signature - Stores a timestamp and a reference to the user's account when the field is 'signed' usually by checking a check-box.  After signing the field becomes read-only and shows the stored timestamp and the name of the user who signed.  Signature fields are unique in that they cannot be completed in any way other that the end user actually checking the box.  All other field types can be manipulated via numerous methods, but the only modifying action allowed on a signature field is to unsign it.  Even unsigning can only be performed by extremely privileged users: an organization administrator (by editing the entry and unchecking the box) or a relate administrator (via formula).
• Document - Stores a link to a document or file.  This type of field also facilitates uploading new documents and creating and manipulating documents via formula.  If the file is an image then the field can generate a thumbnail.  The documents thus linked are stored with and connected to the Relate record in a special document library.  Each Relate record has its own library of documents and files which belong to that record and cannot be connected to a document field in another record.
• Relationship - In appearance this type of field usually looks like a single select or multi-select field:  It presents a list of options to be selected.  However, the options instead of being from a semi-static option list are actually other form entries stored either within the current record or in other records in the system.  Selecting an option makes a connection or relationship between the current entry and the entry selected.  This relationship can be seen and changed from the entry on either end of the relationship.  These fields are difficult to configure correctly, but can be used in very powerful ways.
• Spacer - Not a true field in the strict sense.  This is merely a place holder that directs the system building the automatic layout of the form to add some vertical space between two fields.
• Section Header - Also not a true field, this type directs the automatic layout system to include a section header to visually separate the fields into logical groupings.
• Merge-Report Field - Again, not a true field.  This type of 'field' allows a custom layout to be inserted in the middle of an automatic layout.  Often the automatic layout is exactly what you need...well almost exactly what you need.  In case of 'almost' a merge-report field fills in the gap by allowing a portion of the layout to be custom while retaining the remaining automatic layout.  The automatic layout is able to do many complex functions which are difficult or impossible to reproduce in a custom layout, but by creating a hybrid of the two concepts you can get the best of both worlds.
• Biometric - A biometric field recieves input from specialized biometric hardware input devices.  Not all biometric devices are supported since each requires custom programming.  Currently, the biometric field supports certain fingerprint scanners and signature pads.

Certain types of fields can be used for grouping.  The grouping features are different for different types of fields, but they share a common thread:  groups of fields may become sub-fields to a master field.  The master field determines if and when the sub-fields will be visible.  This is a very powerful concept for creating dynamic and friendly forms.  Grouping fields is simple:  When grouping is turned on for the master field, it splits and becomes two (or more) elements in the field listing.  To put other fields in the group you must reorder the fields so the grouped fields are between the parts of the master field.

Option Lists
As the name implies, this is a list of options.  Each option has a label, an optional export value, display options and identifiers for use in RelateScript.  Option lists are used by text fields, single select fields and multi-select fields to compose a list of options to be selected from.

Wizards
A wizard is used to direct the user through a series of forms to be filled out together.  Wizards are the normal way to create a new record, although the system auto-generates some basic wizards for this task.  Wizards can be used to add a new category to an existing record such as when converting a sales lead to an active client.  Lastly, a special type of wizard, a user wizard, is used to allow a user to enter data into their own account.  User wizards can be used as a sign-up mechanism on sites which allow users to create accounts at will.  Normal or 'general' wizards can be shown in record navigation and thus be used to edit the record and/or add a record category.  Technically users wizards can be shown in record navigation, but this is seldom a good idea.

Merge Reports
Merge reports are so called because they function much like a mail merge in a word processor.   A merge report consists of a block of HTML code with special merge tags inserted throughout where Relate data is to be inserted.  Merge tags can insert data as either read-only or editable values.  Merge reports are often used to create alternate layouts of a form when the auto-generated layout does not meet a particular need.  They can also pull in data from multiple forms onto one screen allowing data from all over a record to be edited or displayed on a single page.  Merge tags can also pull in another merge report allowing re-use of common building blocks.  These building blocks are often combined to create complex layouts from simpler pieces.  Merge tags can insert an entire multi-entry report (see next paragraph).  Lastly, merge reports can contain formulas which read data from throughout the system and do complex calculations or sophisticated user interactions.  Merge reports can be shown in record navigation, be selected as an alternate layout of a form entry being edited or inserted as a merge-report field.  They can be used in numerous other ways which will be touched on later in this document.

Multi-Entry Reports
Composes a report from the entries of one multi-entry form contained within exactly one Relate record..  The report is a table with rows representing entries of the form and columns representing fields on the form.  A partial list of entries can be composed using search criteria such as showing entries from the past 30 days.  The entries can be sorted by any sortable column (some types of data aren't sortable).  Also numeric columns may be totaled, sometimes with sub-totals by grouping entries with a common value in a chosen field.  A multi-entry report may be configured to display a merge report in a column, repeated for each entry being displayed.  In this way multi-entry reports can be used to show much more complex layouts than simple rows and columns.   Also the merge-report-within-a-multi-entry-report technique can be used to edit many entries of the form all at once by choosing a merge report with editable values embedded in it.  Multi-entry reports are often used to present a shortened list of entries from which to select an entry for edit when the total list contains too much historical information to be practical in everyday usage.

Formulas
Formulas use a simple proprietary computer scripting language call Relate Script.  Relate script formulas can be executed on a schedule or be triggered by events in the system such as editing or deleting an entry of a particular form.  Formulas can be used to do complex calculations, send notifications via email and other messaging systems, check newly entered data for compliance with complex rules, and many other things.  A discussion of the capabilities of formulas is beyond the scope of this document.  Read the Relate Script documentation for more complete information.

End Points
End points are advanced formulas that can respond to a raw HTTP request and generate an HTTP response.   They are used to create complex user interactions and communicate with other systems.  Only BlueStep engineers and other specially trained individuals can create and edit end points because their extreme power also makes them extremely dangerous.

Folders
Folders allow relate elements to be created and navigated via a hierarchical folder structure.  A large Relate application may contain several thousand elements.  If not carefully organized and grouped into folders and sub-folders this would be totally overwhelming and impossible to deal with.  Folders are always used to organize Relate elements for configuration within the Relate website.  They may also be shown on the Relate navigation of a record to allow the forms and other visible elements to be grouped and collapsed as the user navigates the record.

Queries and Reports
Queries and reports are much like multi-entry reports (or rather multi-entry reports are like queries and reports).   They display data in a table layout with rows and columns.  The rows of a query or report, instead of representing an entry of a form, represent a record.  And the columns show fields or merge-reports, but they may be from any form or merge-report associated with the records being displayed.  Reports have nearly all of the same features as multi-entry reports in terms of searching and display capabilities.  The only missing feature is they cannot be used to display editable fields.  This is because Relate currently only allows one record to be edited at a time.  Reports have one feature not available in multi-entry reports:  When a row of the report is selected, the report can direct the user to almost any form or merge-report associated with the record.  After viewing the report or editing the form entry, the system can automatically return the user to the report to select another record.  Queries are nearly identical to reports.  They have the additional feature of being able to be searched by the end user while viewing the query results.  Because of this, queries are most commonly used to find a record to work with.  Query's results are also paginated when they are displaying large numbers of records and they do not allow grouping or totalling.  Queries and Reports can also be used to export data from the system in CSV format.

Exercise

Unless you are in a test orgnaization, be very careful doing this exercise.  Any change you make will become effective immediately and may confuse your users or even break existing configuration.

Try to create at least one of each type of element that you can (most users can't create end points, for instance).  Note that record types, folders, option lists, forms and most field types can be created basically stand-alone, without referencing other pieces of configuration.  However, many element types require that other elements exist.  In most cases these elements require that forms and fields exist and that the forms be connected to record types and/or categories.  A few types of elments (relationship fields and merge report fields in particular) are quite difficult to create correctly because they require many carefully configured elements to pre-exist.  Of course, creating a formula will require some knowlege of the BlueStep scripting language.  Full documentation and reference material for Relate Script can be found at clientcare.bluestep.net (this site).  As you create various elements and connect them to each other, observe how your changes effect the applicable records which use these elements.