Skip to main content

Idea pipeline (top 25)

1796 Ideas

Jeroen van den Belt
Administrator
Jeroen van den BeltAdministrator

Table classifications to steer your modelOpen

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.