OutSystems provides a very useful feature for Entities, where developers can quickly generate wrapper actions like Create, CreateOrUpdate, and Delete via right-click. However, this convenience is missing for Roles. Currently, when a Role is Public and reused across applications, developers still need to manually create server/service actions to: Grant Role to User Revoke Role from User Proposed Solution: Add a right-click option on Roles to auto-generate: Grant wrapper Revoke wrapper (similar to how Entity action wrappers are generated) Why This Matters: Speeds up development Eliminates repetitive logic Improves consistency across applications Enhances developer experience in ODC & O11 Real Impact: In multi-application architectures where Roles are shared, this feature would significantly reduce effort and standardize role management. Even if a role is marked as Public, in ODC we can only check the role in other applications, and we still need to manually create actions to grant or revoke roles every time.

We all know that the Aggregate is not usable in some certain situations, for example when you want to use some extensions or when you have a DB fields encryption and so on.I'd like to have an option to transform an aggregate into an advanced query on my code, so I won't waste my time creating lots of joins and filters that I've already created on the aggregate.This would be really helpful and given that you generate the SQL code it seems pretty doable.Best regards,João Carreiro

Hello, The list of components on Profile only matches the O11 components, not reflect the ODC components. Even in Forge when i select My assets only the O11 shows. Best Regards

OutSystems works wonders when the API schema is stable, but many modern APIs return dynamic keys or partially populated objects, especially in integration-heavy and AI-driven scenarios. This creates friction because developers end up relying on custom JavaScript or complex workarounds just to render data cleanly in UI. What developers do today (pain): Build custom logic to extract unique keys Normalize JSON manually (fill missing attributes) Use JS to reshape payloads before JSONDeserialize Manage fragile UI rendering patterns for dynamic columns What I’d love to see improved in the platform: A native Dictionary/Map type for both client and server JSON tooling that supports deserialization into Maps for unknown keys A standard UI binding pattern (even without Data Grid) that allows dynamic columns safely This would reduce dependency on custom code and make OutSystems a stronger fit for modern API patterns. Curious, how are others handling dynamic keys today, and where do you see the biggest friction?

It is known that any Screen/Block in Outsystems Reactive can only be refreshed (when already instantiated) if an input parameter is changed of that Screen/Block.What about having a property in each Input parameter , saying: Reassigned to the same value  will trigger On Parameter ChangeHence, we could detect if any parameter is reassigned to the same value, and if it has that property set to 'Yes', the Screen/Block would trigger an On Parameter Change.

An AI within the development studio/canvas that analyzes complex Aggregates and SQL queries and suggests performance improvements. For example, it could recommend creating new indexes, simplifying joins, using CTEs or temp tables or using more efficient filter patterns based on the data model and query structure. This could be a more granular version of the existing AI Mentor.

Today, when troubleshooting SQL behavior or performance in OutSystems, developers often need to switch between Service Studio and Service Center to understand how queries are being executed. While Service Center is a powerful tool for monitoring, this context switching slows down development and makes it harder to diagnose issues early. I suggest bringing SQL debugging and monitoring capabilities directly into Service Studio, allowing developers to analyze query behavior while they are building and testing their applications, without relying on Service Center for day-to-day development tasks. Possible improvements could include: Visibility of executed SQL details for Aggregates and Advanced SQL Execution time and number of executions shown directly in Service Studio Easy navigation from a screen or action to its related SQL performance data Optional visualization of execution plans or performance hints during development This approach would encourage earlier detection of performance issues and improve the overall developer experience. Use Case In a recent project, I had to work with a fairly large Advanced SQL query that contained several CASE WHEN statements to handle different business rules within the same query. At some point, the screen started returning inconsistent data and, in certain scenarios, became slower than expected. Looking at the SQL itself, it wasn’t clear which CASE branch was actually being used during execution, since the behavior depended on different combinations of parameters coming from the screen. To investigate, I had to copy the SQL from View SQL, run it manually in the database with different parameter values, and then check the Service Center to see execution times and how often the query was being called. This back-and-forth between Service Studio, the database, and Service Center ended up taking a lot of time. It would be extremely helpful to be able to add a breakpoint directly in the SQL, at a specific point in the query, similar to how debugging works in Visual Studio. This would make it easier to understand which logical path the query is following, which CASE condition is being met, and whether the parameters are producing the expected behavior. Having this kind of inspection capability directly in Service Studio, even if limited to development environments, would greatly simplify the process of understanding complex SQL and allow developers to fine-tune queries earlier, without relying on external tools or post-deployment analysis.

We've seen a lot of discussion around Static Entities lately, for example, this idea . While Static Entities provide some value for enumeration use cases, they fall short in a lot of ways: They are stored in the database. They are expensive compute wise (more than they should be) to retrieve. They cost AOs. To use them on client side (other than the ID), they need to be manually synced. Developers need to understand the aforementioned details to use them correctly. Traditional Enums in high code languages are much better. They are directly in the code, making them available at no cost to the caller. Since OutSystems is a giant compiler, Enums should be a first-class construct that: Are compiled into constants rather than stored in the database. Are accessible both server-side and client-side without requiring manual synchronization. Do not consume AOs. Can be used in Service Studio like a variable. Maintain type safety like a Static Entity ID. Static Entities are an old primitive of the platform. I don't believe changing them at this stage is a good move, so I propose creating a new primitive—Enums—that align with modern best practices while keeping the low-code philosophy.

Hi Guys,It would be great if we could access the findings from the Architecture Dashboard from an API.  This is very useful to connect with CI/CD pipelines. Sometimes we had an Architecture team looking for all projects and if we could aggregate the info in one external tool is a must have for us.Best RegardsFabio

While OutSystems UI provides a solid foundation for functionality, the default Layouts (Top Menu, Side Menu, etc.) and screen templates have started to feel a bit dated compared to modern web standards (e.g., Vercel, Stripe, modern SaaS dashboards). Currently, frontend developers spend a significant amount of time overriding default CSS, adjusting padding, shadows, and font hierarchies to make applications look "fresh" and less like a standard enterprise tool. The Idea: I propose introducing a new set of "Modern" Layouts and Themes within OutSystems UI that prioritize current design trends out-of-the-box. What this should include: Cleaner Aesthetics: More generous whitespace, softer shadows, and modern border-radius defaults. Updated Navigation: Sidebar and Topbar designs that feel more like modern SaaS products (e.g., collapsible floating menus, blurred/glassmorphism backgrounds). Typography Focus: Better default font scaling and hierarchy for readability. Native Dark Mode Polish: Improved contrast ratios for the default dark mode. The Benefit: Faster Time-to-Market: Developers won't need to waste time writing custom CSS just to make the app look modern. Better Sales PoCs: Out-of-the-box apps will look impressive immediately, helping sell the platform to UI-conscious clients. Developer Experience: A more inspiring starting point for UI design. Let’s give OutSystems applications a fresh coat of paint by default!