Dataform Field Naming Standards

General Guidelines

Care should be taken when first creating a dataform, as the underlying database table will be generated from the name at the time of creation. For example, if a dataform is added with the name “Certs”, a database table “gen_Certs” will be generated, where “gen_CertificateOfInsurance” would have been preferable. So, when adding a dataform, think about what you would want the database table to be named, then, after it’s created, the form name can be changed to something more human readable or Industry jargonized, without having an effect on the underlying database table.

Field names will be in Pascal Case, which means that field names are created by concatenating capitalized words. For example:

• • FirstName.

  • GrossPayroll.

  • MinAdminPerAccount.

Prefixes are all lowercase. For example:

• • luState.

  • fsOrganizationInformation

When using the ID suffix, both letters should be uppercase. For example:

• • fkEmployeeID.

  • fkUserID

Any fields that store an ID to another entity should have the prefix fk and the suffix ID. For example:

• fkEmployeeID.

A few examples of these foreign key datatypes:

Lookup (core) have the lu prefix. For example:

• • luStatus

Lookup – Multiple (core) have the mlu prefix. For example:

• • mluCommissionMethod.

  • mluCertifications

Checkboxes store a Boolean value (True/False, Yes/No), so they should start with the word Is, Has or Can, depending on what sounds more correct. For example:

• • IsBrokerSubmitted.

  • HasCustomPayroll.

  • CanCreateWorkspace.

Date fields should begin with the word Date. For example:

• • DateReported.

Field Sets should have the prefix fs. For example:

• • fsContactInformation.

Secure attachments should have the prefix sf.

• • sfLossHistory.

All other datatypes should stick to the Pascal Case convention.

Examples: