Naming and field type best practises

A consistent approach to naming, field selection, and validation rules is essential for building a maintainable datamodel. This section outlines recommended standards to apply across teams and projects to ensure clarity, performance, and predictable behavior throughout the application.

Establish Naming Conventions for Your Team

Before creating lists and fields, make naming rules that every developer has to follow. This prevents confusion, makes expressions more readable, reduces errors when referencing fields, and keeps the datamodel readable over time.

Recommended conventions:

• Use descriptive names (e.g., Totalordervalue, not Sum1)

• Use unique names across the entire datamodel, even in different folders

• Avoid special characters; stick to [a-z][0-9] and spaces

• Prefix standards:

  • REF_ for reference fields

  • Calc_ for calculated fields

  • Temp_ for temporary fields or lists

  • OLD_ / XXX_ for deprecated fields

• Always update the technical name when renaming a field

Technical names should be updated when renaming or moving fields to keep paths consistent, prevent hidden reference errors in expressions, and ensure long-term maintainability of the data model.

Field Types

Selecting the correct field type is essential for ensuring clean data and predictable behaviour. Use the smallest and most appropriate type for the purpose, and avoid storing information as text when a more specific field type is available.

Text fields

Keep the maximum length as short as possible, both for validation and for efficient storage. Text fields with 512 or more characters are stored differently in the database and are intended for large descriptions or comment fields.

Recommended lengths for common uses:

• Email address: 150

• Names: 50–75

• Project codes / reference numbers: 20

• Short comments/notes: 512

Using a large text field in a list with many rows can result in an unexpectedly large database. Because storage space is reserved for this field for every row, even when no value is stored, the impact increases significantly as the list grows.

Numeric fields

Use integer or decimal fields for values that must be calculated, sorted, compared, or validated. Avoid storing numbers in text form, as this complicates validation and sorting. Set minimum/maximum values to prevent illogical input (e.g., 0–100 for percentages).

Boolean vs. Concepts

Use a Boolean field when the value is strictly yes or no and no functional middle state is required. Be aware that a Boolean can technically also represent an “unknown” state (for example when no value has been set yet).

However, when a neutral or explicit “no answer” option is functionally meaningful, using a Concept list is the recommended approach. Concept lists make intent explicit and avoid ambiguity in data interpretation.

Use a Concept list when you need values such as:

• Yes

• No

• No Answer / Unknown

This approach is especially useful for forms, approvals, surveys, or optional decision points where the absence of a value has a different meaning than No.

Date and Date-time fields

Use native date fields so you can enforce logic like:

• Start < End

• Birthdate results in age ≥ 18

• Deadlines cannot be in the past

Keep time zone usage consistent across your project. Most applications should standardise on a single fixed time zone (commonly Europe/Amsterdam) unless global scheduling requires conversions. This reduces ambiguity when comparing or validating dates.

Calculated Fields and Expression Calculations

Calculated fields (Calc_) are extremely useful but must be used carefully due to performance implications.

Guidelines:

• Use calculated fields for derived values that change dynamically

• Avoid overusing them in large lists or heavily filtered views

• For performance-critical scenarios:

  • Calculate the value in expressions or logic

  • Persist the result into a normal field

  • Use that persistent field in filters, lists, and UI

Examples

• Calc_Full name = FirstName + ' ' + LastName

• Calc_Project duration = EndDate - StartDate

• For heavy calculations (e.g., budget totals), compute during save and store in TotalCost

Persistent values reduce load on the runtime and ensure consistent results across filters and components.

More information about calculated fields on the next page.