Having identical icons for client and server side built in functions makes it tricky to know which one to use. For example the ListFilter shown below - how is one meant to know which you can use client side and which you can use server side? I remember it like this: client-side one is on top because the request always comes first from the user on the client side - i.e. the first/top one. But I think a slight variation in icons would not be a big change but would be beneficial.

As a developer I want to be in control on which ServiceActions or Events can be used in ODC Workflow. Just to make sure no big mistakes can be made by users not fully trained as developers. Ofcourse I can put them together in one app and make agreements with my Workflow users. But it would be much more convenient and robust to have a property on my Service Actions and Events where I can set if it they are allowed to be used in ODC Workflow

 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.

Statistics on how much time spent on developing an application/module in Service StudioIt will be useful to analyze ourselves  or our team on how much time they will work on the specific application.It will be useful to improve our future works

Ability to zoom in and out in the main window in order to have a better control when inserting or moving elements.

Some application are built specifically for development purposes (SQL Sandbox, impersonate pages etc..) and It would be useful to have a setting which could designate an application as Not For Production to avoid having them deployed into a production environment.This could be a configured on the application level.

In some scenarios, we receive the Id from an API as a text data type, and we need to use it to filter records in an Aggregate. To handle this, we convert the text to a long integer using TextToLongInteger() and then to an identifier using LongIntegerToIdentifier() to match against Table.Id. However, this conversion occasionally fails, especially in the production environment . In such cases, the Aggregate filter fails to return the expected results, likely due to type mismatches or runtime issues with the conversion process. This inconsistency makes it challenging to filter data accurately when dealing with dynamic or external data sources Please consider improving this feature by adding native support for safe and consistent type conversion within Aggregates. This would help ensure reliable filtering, especially when working with dynamic or external data sources, and reduce unexpected issues in production environments.

 Overview OutSystems' 1-Click Publish with comment is a great addition that helps development teams maintain traceability — especially during hotfixes or production changes were knowing why a module was published is just as important as what changed. However, there's a gap in the workflow when publishing through OML upload and Service Center, which undermines this traceability. The Problem In regulated or collaborative environments, teams often follow a change management process where a developer must: Upload the OML file in advance Wait for approval/permission before going live Then publish the module once permission is granted Currently, when uploading an OML via Service Studio, there is no option to attach a comment. This means: If a developer uploads and publishes directly through Service Center (bypassing Service Studio), no publish comment is recorded The permission details, change reason, or hotfix context are permanently lost from the audit trail Teams lose the very traceability that the 1-Click Publish comment feature was designed to provide The only workaround today is: upload the OML, wait for permission, re-open the uploaded module in Service Studio, and then publish with a comment The Proposal Add a Comment Field to the OML Upload Screen: When uploading an OML file via Service Studio, provide an optional comment/reason field. This comment should be associated with the module version and recorded in the publish history if the module is subsequently published. Why This Matters Audit & Compliance: Many enterprises and regulated industries require documented reasons for every production change. A missing comment on a PROD publish is a compliance gap. Team Collaboration: Other developers monitoring deployments via Service Center have no context for why a module was published — especially critical during incidents or hotfixes. Consistency: The comment feature exists in one publish path but not others, creating an inconsistent and incomplete audit trail.

Hi Community, We may end up creating large objects based on our business requirements and there are instances where we need to empty the object or part of it in our logic, as of now we are explicitly assigning "" values by expanding each and every variable from that object, so it would be great if there's a built in function kind of thing to empty the same object or part of it like in traditional coding. Regards, Mahesh

Would be nice to have an option copy a single value from previewed data.PS: Although, I noticed that Ctrl+C copies all the values from the selected column.