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

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.

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

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.

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.

It is possible to consume a REST API using the PATCH method, but it isn't possible to expose a REST API with it. PATCH is meant for selectively updating data (instead of all at once, like PUT). I would like the Platform to support PATCH for an exposed REST API as well.However, PATCH is useless without being able to detect which fields (Attributes) have been sent by the calling party. Currently, if a consuming party doesn't send all the fields, the Platform will set them to the default value. This works for most cases, but not for a PATCH. Therefore, when supporting PATCH, there must be some way (via a runtime property) for the Platform to indicate which fields have been sent, and which were not.

Instead of having only a straight line, see forum post: https://www.outsystems.com/forums/discussion/5275/action-flow-how-to-make-angles-in-connectors-lines/

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.

 Idea Summary Improve the OutSystems Date Picker component to handle DateTime values more accurately and consistently by introducing timezone-aware options and ensuring correct date selection behavior across all data types. Issue Description The current behavior of the Date Picker in OutSystems is inconsistent depending on the data type it is bound to: When bound to a Date type, the selected date is passed and stored correctly. When bound to a DateTime type, the selected date often shifts to one day earlier than expected. This issue appears to stem from server-side time zone conversion, and it becomes particularly problematic in global applications, where users in different time zones experience inconsistent results. Key Improvements Needed Consistent Handling of selected date values regardless of whether the field is Date or DateTime. Time Zone Awareness to avoid unintended shifts due to UTC or server time assumptions. Developer Control via an optional toggle or setting in the Date Picker to treat DateTime values as local dates by default. Suggested Enhancements Add a "Treat as Local DateTime" option in the Date Picker widget settings. Ensure that when a date is selected, it reflects midnight of the selected day in the local time zone unless explicitly configured otherwise. Provide clear documentation or tooltip guidance within the widget for Date vs DateTime behavior. Impact of the Issue Off-by-one-day errors when storing or displaying selected dates. Increased debugging effort due to non-obvious time zone conversions. Reduced trust in date handling for end users, especially in global or multi-regional apps. Higher complexity in development when working with DateTime fields that should behave like Dates. Benefits of the Enhancement Eliminates unexpected date shifts and off-by-one-day errors. Simplifies development and reduces debugging time for apps using DateTime. Improves accuracy and reliability of date-related data across different regions. Enhances the user experience with a more intuitive and predictable Date Picker. Supports global applications where proper time zone handling is essential.