Member Database Setup

NeatClubs.COM provides an advanced interface to define and edit the fields that comprise the Member Database.

This allows the system to be tailored for different membership management applications that may require different terminology or different fields.

The Member Database may include up to 200 fields of various types.  Different field names and data types can be configured, and fields can be associated with fields in foreign database management systems such as Clublink from Integrated Sports Solutions Inc.

When an administrator enters the Database Field Setup screen, the will see the field list as below.  There may be multiple screens of field definitions.  The fields shown below with a cog symbol fields are required and assumed by the system to exist (and that are also assumed to occupy a particular field # location).  While information relating to the presentation of these required fields can be changed or their behaviour, it is important that these fields not be removed from the database (or that the fields themselves be re-named) - for example, NeatWorx will expect that there is always a field name called "fname" and that it will always occupy field #1 in the database.

The Categories are used to group fields together and the Sequence number will determine how fields are ordered within a category.

Database Field Setup Columns

Field #

This is the physical field number or "slot" in the database where this field will be stored. You should never change these field numbers once you have data in the system. If you change a physical field number the database will assume that the field has a new contextual meaning. (when you add new fields, the system will automatically assign new field numbers not in use to avoid conflicts)

Field Name

This is a short symbolic name that we give to a data field item in the database. For example, as explained earlier, “fname” is assumed by the system to always contain a member’s first name. The actual data for the first name however will be always stored in the physical database in “field1”. The database has no knowledge of the meaning of the data item. When the first name is required, the system will first consult these field definitions to determine where the field is physically stored.

Category

The category allows you to “group” like fields together in order. When the form is presented categories will appear in alphabetical order. Whenever a field is presented that is in a new category, a subtitle is created reflecting the new field name. An example is shown below. We have prefixed the category names with numbers to achieve the desired display order for the fields.

Seq

When laying out forms, the “Seq” value or sequence number indicates the order in which the fields should appear. When presenting forms that involve the main membership database records (as above), first fields will be sorted alphabetically by category name, and within each category the fields will then be sorted numerically by their sequence ranking with lower numbers appearing first.

Type

This is the type of data that the field will collect. We will see the different data types and understand their meaning shortly.

Exp

This column in the field view controls whether this field is configured to be exported to a foreign system (such as Clublink or ITSportsNet as examples).

Capture

A graphical icon will appear here indicating whether this field should be captured when a user registers. Often organizations will want to expose only a subset of the fields to their users so as to not over-complicate the form. Missing fields may be populated at a later date. You can hover your mouse over this field to see whether the field is configured to be presented on an initial registration .

Active

The “Active” symbol indicates whether a field is being used in the database. Fields that are not active will be ignored when presenting forms to users. The uid field (representing the user id) is a good example. It has a special meaning to the system, and should be made inactive.  The system will still make use of the field internally, but it will be inactive as far as presented forms are concerned.

We can change the properties of any individual field (including a system field) by clicking on the edit icon () corresponding to that field name.

In this example we’ll examine how the country field is defined. Note that for each field, additional properties are exposed. While this can be a little complex, the ability to adjust the properties of fields at a detailed level saves the need to re-develop portions of the software to meet different customer needs. The detailed properties for the country field are explained below:

Some of the elements that describe fields in the member database have already been covered so we won't bother to explain them again here. Additional fields are explained below.

Field Label Text:

This is the text that is presented on the screen to the user. This is something that can be changed for any time of field to make the field description relevant to your site users. In our example, the word Country appears on the form because this is the label name entered in this field. (the reason the lock symbol appears is that country is a required field by the system, and we want to avoid an administrator accidentally changing the symbolic name of the field. If we did, the system would no longer understand where to find the value for the country)

Field Instructions:

You can provide additional help text so that users will see instructions about how to complete the field when they put their mouse over top of the question mark symbol (). In the example above we provide the text "Please Enter the Country". This can be made more descriptive depending on requirements.

Field is Required in the Schema:

This is what defines a “System” field. You should never change a system field value to “No” since this will allow fields to be deleted. Removing a database field that is required to exist will cause the software to work improperly. This field is exposed mainly to accommodate software enhancements in future.

Field Must be Completed by the User:

This field indicates whether completion of the field is mandatory. If a web-site visitor attempts to press Continue without entering values for mandatory fields, they will see a pop-up message appear like the one below.

Field is for System Use only / Read Only

Some fields have special meaning to the system. The uid field is one of the special fields. As we see below, the uid field has been set to be for system use only. For this reason the UID is not reflected on any of the input screens, but is used behind the scenes by the system.

Field Length:

For Character and Numeric Fields you may specify a field length. This will control the size of the field stored in the . The maximum allowable field length for non-text fields is up to 100 characters.

Display Length:

This value controls the actual size of the field as it will appear on any data entry screen. If the display length is less than the field length the field contents will scroll. For fields with special display formats such as Select fields and Yes/No fields the Field Length and Display Length definitions will be ignored.

Field Category Name:

As explained earlier, this field specifies the name of the logical group of fields that this field is associated with. Since Field Categories are sorted alphabetically, a useful trick is to put a number in front of the category so that lower numbered categories will appear first on the form.

Field Sequence within Category:

This determines the “Seq” value that appeared on the summary view of our member database fields. Lower number sequence numbers will appear on the form before higher numbers.

Field Data type:

This controls the type of data stored in the field. NeatClubs/NeatWorx will handle different data in special ways depending on how this value is set. For example a “Yes/No” field will be assumed to be a Boolean type storing a value of “1” for true in the database or “0” for false. The allowable data types and a brief explanation of each are provided below:

Select String:

If the data type for the field is of type SELECT a comma delimited set of values can be presented that will represent the choices in the select string. For example “Canada,USA”. Note that spaces should not appear beside the commas and the options themselves may not contain embedded commas. The contents of this field will be ignored for non-select data types

Field Visible to Administrators Only:

If this value is set to Yes, this field will only be visible to system administrators updating the member record. This is used with required system fields such as the admin field used to store whether a user has administrative privileges on the system. Only administrators should be able to control who has administrative privileges obviously, so we want to make this field visible only the administrators.

Export this Field to Another System:

If set to “yes”, this field becomes exportable to spreadsheets (CSV exports) and is also exportable to specific integrations with third party systems.

Name of Database Field in Foreign System:

This field is only relevant if you are exporting content to a foreign system. If you are, this field should contain the name of the foreign systems database field. This is how NeatClubs "maps" local fields to remote fields.

User Foreign System Field name as a header in exported CSV files:

Normally when you export fields in your database to a CSV file or spreadsheet, NeatClubs will use its own terminology for the name of the fields. If this option is set to yes however, the field name in the CSV file will be set to use the field name in the foreign system rather than the NeatClubs field name.

A Special Note about the Member Type field

One source of confusion can be the membertype.  As new member records and registration accounts are received, some organizations will want to allow registrants to "self-select" their membership type while others will want members to be "forced" into a particular membership category that is set as a site-wide default or at the event level. (As an example, if a user were registering for a "premium" membership, we would want to force the member type to "premium" behind the scenes, but we would not want users to be able to self-select their own membership type. (they could register themselves for "basic" service, but identify themselves as a "premium" customer if we gave them this ability.

To ensure that the Member Type field is not displayed on a new account registration form:

When the system asks the user to register a new account, as shown below the Member Type field will no longer appear. Other fields can be similarly disabled (although we should always capture the name, Login ID, Password and E-Mail Address)

The other consequence of setting the account like this is that when an exist user registers for an event and is asked to confirm their personal information, the option for the user to "self-select" their member type will not be present.

Forcing User Member Type Validation even when Member Types are not enabled

As if the above were not already a little complex, we have actually run into multiple situations where associations did not want to expose member types to customers on registration, however in the course of a registration event, they still wanted to employ an "honor system" approach allowing members to self-select their member type. This is useful when event fee structures are set to vary based on the membertype of the registrant, and we want to make sure that a member has a chance to correct a profile rather than pay an incorrect fee.

To accommodate this (admittedly rare) circumstance, there is a property under "System Setup" / "Preferences" / "Registrations" called "Force Member Type Confirmation on Event Registration".

If this setting is set to "Yes" the user will be able to self-select their membertype on the screen above even, though the membertype field may be disabled from being captured in the database field setup.