First off, the "Create Action Wrappers" feature is really useful. When you right-click an Entity and generate the Create and CreateOrUpdate server actions, the platform already checks for Mandatory attributes. If a developer misses assigning a value to a mandatory field, an exception is thrown at the application level. That's a nice touch and saves a lot of headaches. One thing I noticed though is that for Text attributes, there is no validation on the defined Length. So if a developer passes a string that is longer than the max length set on the attribute, the value still goes through to the database and you get the classic "String or binary data would be truncated" error. That's a database level error, not an application level one, and it gives the developer zero context on which attribute caused the problem. Since the platform already knows the Length property of each Text attribute (in the Entity definition), it would be great if the generated wrapper could also validate against it. Same pattern as the Mandatory check, just extending it to include a Length check for Text attributes and throw a meaningful exception before it hits the database. This could help by: Making the generated wrappers more complete and consistent Giving developers clearer error messages during development and runtime Reducing unnecessary database round trips for data that was never going to be accepted anyway Really appreciate how the platform already handles the Mandatory side of things. This would just be a nice extension of that same thinking. Would be great to have this for both O11 and ODC. Thanks for considering!

Currently, the Serialize node only provide an option to exclude attributes that have default values. However, there is no option to explicitly exclude custom-selected attributes. This capability is especially useful for logging scenarios . In many cases, creating an additional Structure just to map and exclude specific attributes is redundant and unnecessary. Most serialized outputs are eventually passed to a JavaScript node , written to logs, or stored in a database purely for logging purposes. Allowing developers to select which attributes should be excluded during serialization would significantly reduce development time, keep the code cleaner, and improve maintainability. It would also eliminate the need for extra mapping structures that add complexity without real value.

Although there exist about 15 ideas on improving handling of unused references, non of them state the obvious: it could be done easily by OutSystems fully automatically! My proposal is that developers keep whatever references in DEV (or remove them if they want), but that on deploy to the next environment, OutSystems first automatically removes any unused references, before it starts the deployment. There is in my opinion NEVER a need for unused dependencies in the next environment where someone deploys an application to. As is is never needed, it can always automatically be removed.

While editing a LifeTime plan, I think it would be useful to have a counter that shows how many applications have been added to the plan . When the plan includes a lot of apps, and you know how many need to be deployed, it can sometimes be hard to tell if the numbers match. For example, let's say I have a plan with 25 apps, but I’ve only added 24. With a counter, I could quickly see that one app was missing from the plan. Right now I have to count the apps to see if I have all of them added. Cheers, João Heleno Mockup of a plan with the number of apps showing near the source environment title.

In OutSystems, each Email Web Screen is counted as an Application Object (AO), and AOs directly impact licensing cost. In many enterprise applications, we create multiple Email-related Web Screens (for templates, preview, configuration, triggers, admin panels, etc.), which can significantly increase the AO count. My idea is to replace most Email Web Screens with an Extension-based approach. Instead of building multiple Web Screens for email management, we can: Handle email generation, templates, and logic inside an Extension Store email templates and configurations in the database Trigger emails via server actions or APIs without requiring dedicated UI screens How this helps customers: ✅ Reduces AO consumption by eliminating multiple Email Web Screens ✅ Lowers licensing cost for large-scale applications ✅ Centralized email logic in one reusable Extension ✅ Better performance and maintainability for complex email workflows ✅ Reusable across multiple modules and applications Example Use Cases: Transactional emails (OTP, notifications, approvals) Bulk marketing or system alerts Multi-tenant email templates per client Configurable email rules without UI-heavy admin screens This approach can help enterprises optimize licensing cost while still keeping email functionality flexible and scalable.

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.

If you go to your customer portal, and you have a corporate infrastructure/environment and a personal environment, your personal environment is AWOL in the interface. Please can it show ALL infrastructures/environments please?

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.

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.