Hi everyone,
We are currently migrating applications from OutSystems 11 (O11) to OutSystems Developer Cloud (ODC) and facing a design challenge around implementing a centralized, dynamic menu system.
🔎 Context
In O11:
We had a Menu Web Block inside the Theme module.
It directly interacted with database tables to fetch menu configuration.
The menu was fully dynamic, driven by DB configuration (products, screens, roles, hierarchy, etc.).
The Web Block was public and reused across all applications.
Developers simply dragged and dropped the Menu — no additional logic required.
🎯 Requirement
A centralized configuration app where business users can manage menu entries.
Changes should be reflected immediately across all applications.
Developers should not have to write repetitive logic (fetching menu, handling roles, building hierarchy, etc.).
Maintain a plug-and-play experience similar to O11 while aligning with ODC constraints.
⚠️ Challenge in ODC
In ODC:
Reusable UI components must be placed in Library modules.
Libraries cannot access database entities, which limits building a self-contained dynamic menu component.
This creates a gap compared to O11, where UI, data access, and logic could coexist in a single reusable block.
❓ Key Ask
What is the best way to design and implement this in ODC such that:
The solution remains centralized and dynamic
Changes are reflected immediately across applications
Developer effort is minimal and non-repetitive
We do not compromise the benefits of the O11 approach (re-usability, simplicity, configurability)
Would really appreciate guidance, patterns, or real-world implementations from the community.
Thanks!
Hi @Krishnanand Pathak ,
In ODC, libraries are the right place for reusable blocks, while the menu configuration itself should stay in a central application.
I would create a Menu library with the reusable block and shared structures, and a separate config app that owns the entities and exposes a service action returning the menu data for the current app context. Then each consumer app only needs to call that action and pass the result to the block. This keeps the solution centralized and dynamic, while minimizing repeated logic.
The main difference vs O11 is that the block itself won’t fetch DB data directly, so you won’t get a fully self-contained web block like before, but you can get very close by centralizing all menu-building logic in the provider app.
For more documentation you can check this article: Asset consuming an ODC application Block - OutSystems 11 Documentation
Hello @Mihai Melencu,
Along with Mihai’s insight, for this scenario I would approach it as follows:
For the reusable menu configuration, as you mentioned, in O11 it is typically handled through database configurations, roles, and similar setups.
If you are using normal entities, then you can create a separate application, for example a Config App (as Mihai suggested), and include the entities there. This app can also consume entities from other applications. In ODC, you do not need to worry much about dependencies since it follows a loosely coupled architecture.
If you are using static entities, then things become much simpler. In this case, you can place them inside a library. You can include them in the same library that holds your theme. However, I would recommend creating a separate library, for example something like _Pat (patterns), especially if you plan to add reusable components such as customizable widgets or inputs in the future.