The proposal aims to enhance the performance of the OutSystems built-in ListAppendAll function. Currently, ListAppendAll iterates over the source list using a foreach loop, invoking the ListAppend action on each iteration. This results in multiple dynamic array resizings, as each call to ListAppend extends the underlying array incrementally, leading to performance overhead due to repeated memory allocations and data copies. In contrast, in native C#, the List.AddRange method optimises this process by pre-allocating the required space in the underlying array in a single operation. It then efficiently inserts elements using Array.Copy, minimising reallocations and improving execution time. Implementing a similar bulk append mechanism in ListAppendAll would reduce memory overhead and improve performance. The attached files include the BenchmarkDotNet results and the code used for performance testing. Tested on .NET 4.8.1 and Intel Core i7 12800HX processor. While the code does not exactly replicate the OutSystems implementation, it follows a similar approach to demonstrate potential performance improvements.

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.

An app where developers can create AI Agents using Mentor inside ODC, guided, structured, and production-ready. A lightweight app that helps developers: Define an Agent purpose Generate the System Prompt Suggest Actions Recommend Grounding strategy Propose Memory configuration All using AI guidance with Mentor.

ODC Portal should have a screen with a interface to manage all the setting of the OuSystems Cloud connector, instead of a command line.

Create a Edit Button in this space for changing the Idea Title. In this moment if we make an error when we create a new idea we don't have the opportunity to correct. Its my new suggestion. Best Regards, Paulo Russo.

The availability of the Trace API download functionality, currently supported in OutSystems 11, should be extended to OutSystems Developer Cloud (ODC). We already have "Traces" at ODC portal that contains useful information when API fails , however doesn't have the request and response payload. This level of detail is a critical asset for development and troubleshooting. It enables faster debugging of API issues by allowing developers to verify payload correctness, understand provider errors, and ensure that the application complies with contract expectations (all of which are hard to validate without full trace access) Additionally, since OutSystems 11 already offers this functionality, bringing it to ODC would ensure consistency for teams migrating or working across both platforms, improving developer experience and efficiency.

There are plenty of scenarios in which the base built-in actions are not enough. For example, if creation of a specific entity record demands that other entity records be also created, or if certain restrictions apply that cannot be modeled with static "default values". Or simply because you want to audit operations over sensitive entities. Currently the way to do this with the Agile Platform is clumsy: isolate entities in their own eSpace, make them available read-only, and create sets of actions to do the required tasks. This works, but: It is ugly - when actually using those actions, you will not see them associated with entities; you need to remember that they need to be imported, look for them under "referenced actions", remember from which eSpace they come from - or go look in the entity list; It can lead to errors - if a new developer in a project using the pattern, for some reason, is not properly informed, he might simply go into the eSpace and switch the read-only property off, anticipating that it being that way was an error.

I don't know if there is somewhere else for this... https://learn.outsystems.com/training/journeys/web-developer-exam-2993/best-practices-for-building-screens/odc/6729 There's explicit instruction elsewhere in the training NOT to use Check###Role() on the enabled button, but to only use it on the visible property, because you can just hit F12 and enable the button.

Implement a "Conflict-Free Data Replicated Type " (CRDT) based editor that allows two developers to work on the same screen or logic flow simultaneously, seeing each other's changes in real-time without needing a manual merge

I would like to suggest that applications relying on deprecated elements (marked as DEPRECATED_) be considered as technical debt in the AI Mentor platform. By considering applications that depend on deprecated elements as technical debt, we can prioritize their resolution and allocate resources to address them accordingly. This approach will help us ensure that the AI Mentor platform remains up-to-date, efficient, and aligned with industry best practices. Thank you for considering this suggestion. I believe that by actively managing technical debt related to deprecated elements, we can enhance the overall quality and maintainability.