I've seen many of these 'generic' master entities as long ago as the 90's.  In those days, developing maintenance software was more expensive (now it is a matter of scaffolding) so it kind of made sense.

I see a lot of desire to reduce AO by reducing static entities, but what you are proposing is only kind-of usefull if you look at statics as a bag of options to choose from (like a dropdown), in that case, yes, just filter by type and your dropdown will only show the applicable values.

But static entities are not only tables with a few rows, they also act as enumerations, allowing you to write code against them.  This will get much uglier / harder / error sensitive for your developers.

For example if they want to write an assign, setting the status fo a request to Rejected, the number of options from which they will have to try and pick the right static record will be very confusing and error prone.

compare this

to this

In large OutSystems applications, AO consumption can become a bottleneck.

Since each Static Entity counts as an AO, reducing them significantly impacts the overall AO count.

A single Master Static Entity allows multiple dropdown-style lists to exist under one AO unit, making it an effective way to manage AO consumption in OutSystems.

Many static entities only serve as selectable options in dropdowns (e.g., Countries, Currencies, Order Statuses, etc.).

For these cases, a single table with a “Type” column can replace multiple small Static Entities without affecting business logic.

Developers only need to filter by the Type attribute to get the relevant list of values.

in that case (only to serve as source for a dropdown), no need to make it a static entity, you can just use a normal entity for this.

But regardless of whether this is something an OutSystems factory wants to do, this Ideas section of the website is for ideas about what OutSystems can do to improve their product.

Are you proposing that the platform / Service Studio does something to facilitate this ?

Currently, every Static Entity in OutSystems consumes AO (Application Objects), even when used only as a simple dropdown source. To reduce AO consumption, developers often consolidate multiple Static Entities into a single Master Entity or use normal database entities instead. However, this requires additional filtering logic and makes maintenance slightly harder.

OutSystems could introduce a built-in, AO-free "Dropdown Data Source" feature in Service Studio that allows developers to:Define dropdown values without consuming AO.Store static dropdown values efficiently, similar to Static Entities but optimized for AO usage.Optionally auto-generate dropdown data from an external API or database table.

Benefits:

Reduces AO consumption while keeping dropdown management simple. Avoids unnecessary workarounds, such as consolidating multiple Static Entities into a master table. Improves maintainability, as developers don’t need to manually manage dropdown options in normal entities. Enhances performance, since dropdown values are cached like Static Entities but     without the AO cost.

The idea is good, makes sense. But you know, changing the core of the platform takes year, or years. And it doesn't benefit the existing projects. Static Entity is enough now, good concept, easy implement, the main problem is cost. 

If Outsystems can reduce Static Entity's cost, problems will be solved, no need updating platform, knowledge documents..., existing projects don't need to be refactored, on-going project still works, future project will be easier, things will immediately affected.

hi @Suryanarayan Vundru 

if you have a Large Number of generic LOVs (Look up values) which are only used for drop downs for Meta data you can implement this just as you suggested with 2 entities .

1. Master Type Table
2. Master record table with Master type as the Foreign Key

As shown below

This will be useful to store multiple Meta data LOVs using just 2 AOs, Indexing the Master Type will ensure no performance bottle necks as well

@TheSubuIyer 

We're doing that way to store master data. And for more convenient in migrating data from Dev to Prod environment, It better adding new MasterTypeCode attribute instead of using Auto Generated Id :)

@Kiet Phan 

Yes Absolutely. That will be easier for download and Upload even boot strapping