Settings and Value Tables

Settings and value tables manage simple lookup data such as statuses, categories, tags, countries, venues, or other controlled lists.

They allow project teams to maintain recurring values without treating those values as ordinary workflow records.

Settings Purpose

Controlled Values

Settings are useful when users choose from a controlled set of values.

For example, a project might have status values, categories, countries, departments, venues, document types, or application rounds. These values can then be reused in fields, filters, queries, and reports.

Project Maintenance

Some settings need to change during the life of an application.

If values may be added, renamed, sorted, deactivated, or translated by administrators, they usually belong in a configurable settings area rather than being hard-coded into the application.

Value Tables

Simple Lookup Tables

A value table usually contains short records used by other parts of the application.

For example, a category table might contain a name, language-specific labels, a colour, a sort order, and an active state. The records in the table are then selected from fields elsewhere in the application.

Operational Records

Not every small table is a value table.

A table should not be treated as a setting merely because it has few records. If the records belong to a real workflow, contain project activity, or represent something users manage as part of daily work, they may need their own module instead.

Settings Access

Administrators

Settings areas are often limited to administrators.

This keeps controlled values stable and prevents ordinary users from changing options that affect forms, queries, exports, reports, or workflow logic.

Visibility in the Application

Settings can appear as their own administration area or as supporting modules.

The right structure depends on how often the values change, who maintains them, and whether users need to understand the values as part of their daily work.