Calculated, transient or session?

Calculated, Temporary and Session Fields

WEM supports three main types of non-persistent data: calculated, temporary (transient), and session fields. Choosing the correct approach for each situation ensures predictable behaviour, good performance, and a clean datamodel. This section explains how each type works, when to use them, and the differences between the “old” and the new Kubernetes-based session model.

Temporary (Transient) Fields

Temporary or transient fields are fields not stored in a database list. Their values exist only within the current context of that interaction and are commonly used for:

• User-selected filter options

• Input values before saving to a persistent record

• Import processing (temporary import lists prefixed with Temp_)

Characteristics of transient fields

• Each browser tab holds its own values

• Values can differ between tabs

• Values are cleared when the browser tab cache

• Browser behaviour may occasionally restore transient state if the browser has not fully terminated

Transient fields are suitable for most temporary storage and UI state management. They are the default choice unless cross-tab sharing is required.

The New WEM Session Folder

The Session folder is used to store session-based data that exists only during a user’s active session. These fields are not persisted in the database and are primarily used for authentication state, permissions, and temporary cross-page or cross-tab logic.

Characteristics of the new session fields

• Values are shared across multiple tabs for the same user

• A session field has one value per user session, not per tab

• Back-button navigation cannot revert session values

• Values may persist if the user reopens the application shortly after closing the browser

• Session values remain until session timeout or until explicitly cleared (e.g., “Clear Session” in logout flows for example)

When to use the new Session Folder

Use session fields for values that:

• Must be identical across all open tabs

• Must not change when navigating backwards

• Should persist across a browser restart within the session timeout

• Represent application-level user context

Typical examples

• Current user reference

• Selected viewstates

• Shopping cart / selected item lists

• A shared “current project” or “current employee” reference across multiple views

When not to use the Session Folder

Keep the following in the normal transient area:

• Search or filter fields (users may filter differently per tab)

• UI-display toggles unless cross-tab consistency is required

• Any field where changes in one tab should not affect another

In general:

Use transient fields for most situations; use the Session Folder only when you intentionally need session-wide, shared behaviour.

When using the Current User reference field in the Session folder, ensure it is properly validated and handled. The application must behave safely when the value is empty, invalid, or unavailable, to prevent unexpected or insecure behavior.

All functionality that depends on the logged-in user should always use this single Current User reference field. Avoid duplicating user references elsewhere in the model, as this can lead to inconsistencies and security risks.

Calculated Fields

Calculated fields (Calc_) compute a derived value at the moment they are used. These calculations are executed by the runtime and should therefore be written in a way that is SQL-compatible. Poorly structured or non-optimised expressions can lead to unnecessary load, especially when calculated fields are used in large overviews or with difficult calculations.

Calculated fields can represent constants, dynamic values, or expressions that are used across the application. They provide a powerful way to centralise logic, but should be designed with both maintainability and performance in mind.

When to use calculated fields

• For values that are derived from other fields

• For application constants (VAT percentage, default email address, API keys, fixed dates)

• For reusable logic that should not be duplicated across expressions

Useful practice: Use CF_ fields for constants

Instead of hardcoding values into expressions, store them in a calculated field. This ensures they can be changed in one place without searching across templates and flows by using the find usages feature.

Calculated Fields and Performance

Because calculated fields compute their value on demand, heavy or frequently used calculations can impact performance. If a value rarely changes or is used extensively in large overviews, consider storing the result in a persistent field and updating it periodically through tasks.

Approaches for performance optimisation

• Make SQL compatible expressions, these fields suffer from improperly optimised expressions

• Cache the value by writing the calculation into a persistent field during a nightly/periodic process

• Store the calculated value when a record is saved or updated

• Use transient fields to hold heavy values temporarily during a session

This may deviate from strict normalisation, but greatly improves user experience in large lists or dashboards.

The calculated fields can be very useful for reusing and later finding boolean checks like ispreview() or isstaging(). When this is a calculated field in the datamodel the find usages feature can then be used to quickly see where there are still preview or staging checks on features ready for release.

Summary

• Transient fields are per-tab and ideal for most temporary UI and process data

• Session Folder fields are shared across tabs and persist until session timeout

• Calculated fields centralise formulas, reusable logic, and constants

• Calculated fields are recalculated every time the fields is used, risking performance issues when used incorrectly.

• For performance-heavy calculations, and update with background tasks