> 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/data-model-checklist.md).

# Data model Checklist

* [ ] **Choose folder structure strategy**
* [ ] **Create logging strategy**
  * [ ] What events should be logged?
  * [ ] How long can they be stored?
* [ ] **Define deletion and archiving strategy**
  * [ ] Is Soft delete (`IsDeleted`) necessary?
  * [ ] Retention periods (GDPR or business rules)
  * [ ] Archival lists if applicable

### 1. Define the Storage Strategy *(before project creation)*

* [ ] Decide on **shared or separate data models**
* [ ] Choose folder structure strategy
* [ ] Define time handling strategy
  * [ ] Use a fixed (UTC) time zone
  * [ ] Or implement explicit time zone conversion logic

***

### 2. Define Folder Structure

* [ ] Feature focussed structure or Field function focussed

***

### 3. Identify Core Entities & Relationships

* [ ] Identify core application processes
* [ ] Define main data lists (e.g. Employees, Projects)
* [ ] Identify and define relationships between data entities

***

### 4. Classify Data Types

* [ ] Identify which data is **persistent**, **temporary**, or **session-based**
* [ ] Persistent database fields
* [ ] Temporary fields (`Temp_`) for UI and process logic
* [ ] Session fields (if Session Folder is used)

***

### 5. Define Prefixes Rules and naming convention

* [ ] Create naming guideline
* [ ] Apply prefixes consistently:
  * [ ] `REF_` (references)
  * [ ] `Calc_` (calculated fields)
  * [ ] `Temp_` (temporary/transient fields)
  * [ ] `OLD_` (deprecated fields)

***

### 6. Design Logging Strategy

* [ ] Determine if logging is required (and why)
* [ ] Define which events should be logged (and why)
* [ ] Define which information should be logged (and why)

***

### 7. Define Deletion & Archiving Strategy

* [ ] Decide where soft deletion or archiving is required
* [ ] Define retention periods (GDPR or business rules)

***

### 8. Apply Validation & Data Quality Rules

* [ ] Use valid value rules
* [ ] Use process validation rules where needed
* [ ] Set numeric min/max values
* [ ] Set maximum text lengths

***

### 9. Optimise Calculated Fields

* [ ] Ensure SQL-compatible and efficient expressions
* [ ] Review heavy or frequently used calculated fields
* [ ] Cache or persist calculated values when appropriate

***

### **10. Identify Performance Risks**

Performance issues usually stem from design choices that only become problematic as data volume grows. Regularly review your data model to identify potential performance risks early.

Focus on:

* [ ] Large lists with high row counts
* [ ] Calculated fields used in overviews, dashboards, filters, or repeating UI components
* [ ] Heavy or unoptimised calculated field expressions (SQL compatibility)
* [ ] Large text fields (>1024 characters) in high-volume lists
* [ ] Rapidly growing logging or API-related lists
* [ ] Session fields that are updated frequently or shared unnecessarily across tabs

***

### 10. Review & Maintain the Data Model

* [ ] Remove unused fields
* [ ] Mark deprecated fields as `OLD_`
* [ ] Verify naming consistency
* [ ] Re-check validation rules

Periodically review performance and data growth


---

# 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/data-model-checklist.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.