As confirmed by OutSystems in this forum topic , data fetch actions are not optimized and instead passing all screen data in every request payload. Even if the parameters are not used anywhere in the data action. Please optimize this.

like to see service studio having a inbuild animated icons like animated SVGs

Currently, OutSystems UI provides built-in Open and Close actions for individual Tooltip components. However, if we review the Tooltip API implementation, we can see that there is also a GetAllTooltips method available. https://github.com/OutSystems/outsystems-ui/blob/53a8f0e/src/scripts/OutSystems/OSUI/Patterns/TooltipAPI.ts#L2 If you want to show all the tooltips in the screen you need to rely on a iteration and trigger the open tooltip action. Add the GetAllTooltips and ShowAllTooltips to the list of OutsystemsUI Actions.

like switching between different devices , switching between design modes in the studio

Hello Everybody,I want to propose a new idea:The possibility of the lifetime applications can be divided by different streets Why is this important?When you have an infrastructure with many environments (9 in my case), it becomes difficult to make the management through the lifetime applications list The problem:I have 6 environments in my infrastructure and two DEV environments(Street 1: DEV, TST, PRD) + (Street 2:  DEV, TST, PRD)When developers publish the second DEV Environment (BA DEV) they get a warning like it’s a hotfix and that they should propagate to the previous environmentsBut I don't wanna propagated backwards because I'm developing in a new street of environments. The solution :Add the possibility to create Streets and shows only the environments in this street.

When doing a refactor of the CSS or changing a class, it would be nice to know where it's being used through all modules to prevent breaking something that we already have.You could improve the search that we already have to allow this.

Today, AI Mentor (App Generator) is powerful when it comes to validating best practices, architecture, and quality of applications already developed in OutSystems. My proposal is to expand this capability so that the Mentor can read external source code (for example, from a Git repository, in languages such as Java, .NET, Node.js, Angular, etc.) and: Analyze the structure, business logic, integrations, and existing architecture patterns in the legacy code. Automatically suggest how this code could be rewritten in OutSystems, following modularization, security, and scalability best practices. Generate initial components (entities, actions, APIs, UI blocks) inside an OutSystems module as an acceleration base for migration. Value for the Community and Customers Accelerated migrations: companies with legacy systems could move to OutSystems much faster. Reduced risk: the process would become more predictable and auditable. Productivity: developers focus on evolution instead of manual migration work. Governance: the automatically generated application would already comply with AI Mentor’s best practices. Example Use Case Migrating a management system in .NET/SQL Server to OutSystems. AI Mentor connects to Git, reads the code, identifies entities, logic, and integrations, and suggests a skeleton in OutSystems that developers can refine. Expected Impact Disruption in the modernization process of legacy applications. Competitive advantage for OutSystems compared to other low-code platforms. Faster adoption of the platform by large enterprises with extensive legacy systems.

 Problem: Validations are hard, time-consuming and error-prone. Currently, OutSystems structures only define shape, not validity. A lot of projects end up lacking validations because of the effort involved in developing and maintaining them across client and server side. Proposed Solution: Introduce a Schema primitive (similar to Zod and Valibot ) that would define the shape (fields) and also the rules (declarative validation definitions that validate the field contents at runtime ). It would be defined in Service Studio and have an IsValid runtime field that developers can check to assert the validity of the data. An Issues field (list of Issue ) would identify which fields are invalid and the reason. The Schema should be universal, meaning it could be used to validate data both on the client and on the server side based on the same declarative rules. I think this would greatly improve developer speed and application security in our OutSystems applications.

To have a 'Find Usages' function for API clients created in ODC portal. When we expose API thru libraries, we can add ClientId and ClientSecret as settings. Then we will add the values, in the actual consumer app settings in ODC portal. Since there can be a lot of application using same ClientId and ClientSecret, it will be useful to have a 'Find Usages' for the actual API client created. This will allows for easy governance, and also ensure the correct app is using the correct API client.

When you name a variable the Outsystems platform automatically sets a data type based on that name. When you create a new variable, this behavior is mostly correct and helpful. Sometimes however, the platform is just plain wrong in guessing the data type. No sweat, you change the data type manually and the problem is solved, so you would think...However, when you now copy that variable and change the name of that copy, the platform again tries to guess the data type and, yes, again it guesses wrong. Even when you rename the original variable the same thing happens: wrong data type again. The result of this behavior is that you have to manually change the data type again, and again, and ... yes, every time you rename a variable! This becomes a frustrating exercise very fast!To prevent this issue I would like to propose that setting the data type of a variable automatically is NOT performed when either,- the data type was set manually by the developer- the variable was copiedPlease vote for implementing this if you agree.