> For the complete documentation index, see [llms.txt](https://docs.wem.io/platform/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.wem.io/platform/tutorials/tutorials/setting-up-a-datamodel/naming-and-field-type-best-practises.md).

# 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

{% hint style="info" %}
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.
{% endhint %}

### 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**

{% hint style="info" %}
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.
{% endhint %}

#### **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.

{% hint style="info" %}
More information about calculated fields on the next page.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.wem.io/platform/tutorials/tutorials/setting-up-a-datamodel/naming-and-field-type-best-practises.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.