GraphQL is an API standard that provides a more efficient, powerful and flexible alternative to REST web services.Source: https://graphql.org/

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!

A mobile application that allows developers to join User Group events anytime, even when they don’t have their laptop. This makes event participation easier, increases accessibility, and encourages more developers to attend and learn from OutSystems community sessions.

It would be really great if you in someway could organise your service studio. There are of course possible ways, like;- adding folders (the independent modules is a kind of misc folder)- 4-LC organisedIf this structure is also applied in the Manage Dependencies, that could also really help in finding the right modules  :-) This could be another idea in itself...

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.

Add tools to allow the enhanced organization of application icons in the user's environment in Service Studio. Filter, Sort, View mode (List, thumbnails, ..), ...

Hi, ODC PE navigation and functionalities have bugs and logic isn't user friendly. 1.1. Cannot login with the username and password from the owner of the environment in an app. 1.2. Cannot edit created users or add a password to them. Name keeps as "Unnamed user". 1.3. Result: without proper setting up the users, we cannot use the apps that we test before implementing them in the client. 2. Remember Me in ODC login doesn't work. After several minutes we need to insert credentials again. 3. Login in ODC Studio should be available inside the app, without needing to do it in the browser. Browser login should act independently, specially if we want to login in apps with other users. 4. Make available Login action in server side so that a system user can be added 5. There isn't a button to open ODC Studio without opening an app. 6. Add more logs to the Logs, like we have in O11 Service Center. Just published an app and gave an error and nothing appear in the logs. We need to have more in-depth information in the logs. 7. Messages used in "LogMessage" action don't appear in the logs. 8. Add sort in apps in ODC for Created Date. 9. Add details in ODC in each functionality. 10. Add details in Platform Updates to know the impact of updating. Note: A Developer should have control at all times of what he is doing. For that, more information is needed and ODC doesn't provide enough control on performed actions or in logs. There are several O11 features that should be implemented in ODC. Simple is not always better, specially in an enterprise platform, as control should be the drive in this case.

I would like to right click on a Entity in a non-production Environment and generate one script with delete in cascade to clear all the records from that entity and avoid the error "The DELETE statement conflicted with the REFERENCE constraint".

When the screen has too much information and the performance starts to decrease one of the options we have is to create a web block with some of that information and do a lazy load.It would be nice to have something similar to "Extract to action" where you can select the elements in the screen and "Extract to Web Block".In case of a table, it would:- Remove the query from the preparation of the screen into the preparation of the Web Block;- Remove the actions from the screen into the Web Block;- Remove the selected elements into the Web Block;- Add the necessary input parameters to the Web Block.

Problem: Currently OutSystems ODC provides the User and access management API and Portfolio API to access the platform functionalities from code. However, connection is done via a custom consume REST Connectors, and they consume quite a lot of AOs to one's license (15+). This also Proposal: Connectors, that do not count towards the total AO count of a license. This could be achieved via a couple of alternative options: -an OutSystems-provided official connectors, that similarly to the System's libraries do not count towards the total AO consumption -unsupported custom Forge Connectors (like now), that have the option to be reviewed and aaproved by the OutSystems team, and they do not count towards the AO consumption -out-of-the-box way of consuming the APIs as part of the platform (inside System library Actions or similar)