Planning a datamodel

Planning your datamodel

Before creating lists or fields in WEM, it is more strategic to first understand the application you are modelling. Proper planning ensures that the datamodel is clean, scalable, and supports both current and future requirements. This section outlines the recommended considerations when preparing a new datamodel.

Storage Strategy: Shared vs. Separate Data-models

When planning a datamodel, you have to determine early whether portals will share the same datamodel or use separate databases.

If the various portals in a project all need their own data and/or prevent users from the other portals to access the data (like with a multi-tenant solution), you should choose to separate the databases (each portal its own storage). On the other hand, if the users of the various portals can or even must share the data, you share the database (this is the default setting when creating a new project).

NOTE: you can only specify the storage strategy (shared or separate), at the time when you create the project or shortly thereafter.

This setting cannot be changed once the project is previewed or published - because either of those actions will create the database container based on the chosen strategy - and, once the container has been created, it cannot be changed.

A consideration is that even when a database is shared between multiple portals you can still build the application to only show specific data depending on the portal. This costs more development time but it allows have both the functionality of a shared and a separate datamodel.

Organise and Standardise Folder Structure

Setting up a folder structure at the start of a project is important to stay organized and speed up development. A clear structure improves navigation, reduces duplication, and makes collaboration easier.

There are two approaches to structuring the data model that we work with. The right choice depends on team size, project complexity, and how closely team members work together.

Option A – Feature-Oriented Structure (Current Approach)

This structure makes it easier to match a feature with its related data and find the corresponding flowcharts. This type creates similar fields that need to be recreated for each feature and does not promote easy reusability of fields. The search field for name for example will be recreated for each feature.

When to Choose This Structure

This approach works best when:

• The project involves larger teams

• Teams work relatively independently on separate features

• Fields are primarily used within a specific feature context

• Clear ownership per feature is important

It improves isolation and reduces the risk of accidental cross-feature impact.

• Authentication

• Subject 1

• Subject 2

• System

  • Settings

  • Utils

  • Variables

• Subject 3

• (Optionally: retired or archived)

Each subject or feature folder has its own default subfolders:

• Subject 1

  • [Database list]

  • Filter fields > used in overview filters

  • Permissions > calculated fields to determine a role

  • Settings > calculated fields

  • Variables > transient fields in

The session folder/section is mostly used for authentication and permission purposes. This list can later be expanded subject folders for features that use make use of this folder.

• Authentication

• Permissions

Option B – Layer-Oriented Structure

In this structure, separation is made by application layer instead of feature domain.

When to Choose This Structure

This approach works best when:

• The team works closely together

• There are strong agreements about naming and reuse

• Reusability of fields is a priority

• Developers frequently search across the entire model

It improves:

• Discoverability via search

• Reuse of shared fields

• Centralized management of logic

However, it requires more coordination and discipline to keep the model clean and consistent.

The default top-level folders are:

• Feature x

  • feature central data-lists

• Process

  • Filters

  • Transient fields

• System/ Settings

• (Optionally: Retired or Archived)

Within these folders, lists and fields can either:

• Be placed directly, or

• Be further grouped by functionality for larger applications

Recommendation

Both structures are valid. The choice should be made consciously at the start of the project and aligned within the team.

• If the project is large and team members are relatively disconnected, choose the feature-oriented structure.

• If the team works closely together and reuse is a strong priority, choose the layer-oriented structure.

Consistency within a project is more important than which option is selected.

Identify the Core Entities and Relationships

Start by determining which real-world objects the application needs to store. These will become your primary lists. Consider how they connect and whether relationships are one-to-one, one-to-many or many-to-many.

Example (Employees & Projects) In a system where employees work on projects:

• An Employee can be assigned to multiple Projects

• A Project can have multiple Employees

• This relation is many to many for both ways

This results in:

• Users (list)

• Employees (list)

• Projects (list)

• Assignments (joining list for the many-to-many relationship)

During this step, avoid sublists unless data belongs exclusively to a single record and will never be used independently. In most cases, a joining list is preferred over nested structures.

Date and Time Strategy

Date and time handling must be defined early in the project. Time configuration affects validations, scheduling, logging, integrations, and system-generated timestamps.

There are two levels to consider:

1. How time is stored in the data model

2. How time is shown to users

Data Model Time (Storage)

When committing date/time values to the data model, the recommended best practice is:

Store all date/time values in UTC.

This includes:

• Manually entered date/time fields

• Automatically generated fields (e.g. Created On, Last Modified)

• Values returned by runtime functions such as now()

• Timestamps generated in scheduled tasks or integrations

Why UTC?

• Runtime installations often operate in UTC

• Functions such as now() return the system time of the runtime environment (often UTC)

• Can avoid daylight saving time issues

• Ensures reliable integration with external systems

Storing time in UTC creates a consistent and predictable baseline

User Interaction Time (Presentation)

Time should only be translated to local time when:

• Displayed in the UI

• Used in user-facing validations

• Exported for human interpretation

This separation ensures that storage remains consistent, while the user experience remains intuitive.