Skip to main content
Open

Table classifications to steer your model

Related products:Software Factory
  • September 29, 2025
  • 3 replies
  • 51 views

Jeroen van den Belt
Administrator

I propose introducing the ability to assign a classification to a table.

At a basic level, this would help with simple tasks such as identifying, sorting, or filtering related tables within the platform.

At a more advanced level, the classification could be used to drive specific behavior that reflects the nature of the table. Initially this behavior can be implemented by yourself through the dynamic model, while in a later phase the configuration could potentially be formalized in the SF.

Examples of table classifications could be:

  • Master: Contains base data such as VAT rates, product categories, currencies, countries, languages, ISO codes, and date conversions.
    • Example behaviour: Make editable, with the awareness that adjustments may have significant impact.
  • Configuration: Contains configurable items such as email settings and system parameters.
    • Example behaviour: Make read-only once accessed from a lookup since adjustments often have unintended consequences.
  • Core Entities: Contains strong entities such as customers, suppliers, and employees.
    • Example behaviour: Apply a screen type which lets you easily see, manage and add these core entities.
  • Operational: Contains process data such as appointments, orders, and invoices.
    • Example behaviour: Provide transactional screens to create, edit, and process these records in line with operational workflows.
  • Interface: Tables that act as a bridge between external systems and the application, such as API staging tables, integration views, or import/export buffers.
    • Example behaviour: Do not require translations, exclude from UI-related validations to prevent unnecessary validation messages.
  • Analysis: Contains analytical structures such as dashboards, reporting, and BI aggregates.
    • Example behaviour: Make read-only for analytical purposes.
  • Archive: Contains historical data such as past invoices and legacy records.
    • Example behaviour: Make read-only for long-term storage.
  • Logging: Contains system/user events such as audit trails, login attempts, and error logs.
    • Example behaviour: Make read-only, automatically place in a ‘Logging’ menu group.
  • Staging: Contains temporary storage such as import buffers and preprocessing tables.
    • Example behaviour: Allow only temporary use with minimal validations, and ensure automatic cleanup or further processing.

3 replies

Mark Jongeling
Administrator
Forum|alt.badge.img+23
  • Administrator
  • 4053 replies
  • September 29, 2025
NewOpen

Forum|alt.badge.img+8
  • Captain
  • 67 replies
  • September 29, 2025

I have used table tags for a very similar classification, but having a dedicated field would be much nicer.

Optionally I would like to be able to configure per model in the SF if the table classification is mandatory. 

 


Jeroen van den Belt
Administrator
Forum|alt.badge.img+10

@PeterKeeris Thanks for your additions. If you have any examples of other classifications, or other relevant example behaviors why you applied those tags, please let me know.