Inside an aggregate comparing the same variable (inside a filter) should trigger a warning. If an aggregate filter says user.id=user.id it should trigger a warning clearly this will always be true. the user would have likely meant user.id=userid

OutSystems certifications are highly valued by developers and organizations worldwide. However, unlike many other global certification programs (e.g., AWS, Microsoft, IBM), OutSystems currently does not issue Open Badges for its certifications. Open Badges are digital credentials that embed metadata into badge images, making them verifiable, shareable, and portable across platforms. They are standardized by the 1EdTech Consortium (formerly IMS Global Learning Consortium) and widely adopted in education and industry. https://www.imsglobal.org/spec/ob/v3p0/ By enabling Open Badge support for OutSystems certifications, the platform can: Increase visibility and recognition of certified professionals Improve integration with digital portfolios and LinkedIn profiles Align with international standards for credentialing Enhance motivation and engagement among learners Implementation can be streamlined using existing platforms like Credly, which many organizations already use for badge issuance. The cost and operational burden are moderate, and the benefits in branding, community engagement, and learner experience are significant. We hope OutSystems will consider adopting Open Badges for its certification programs to further empower its developer community and strengthen its global presence.

This looks more like a bug, but as per requested by the Support team here the details: Apparently, containing special chars like : in the URL is problematic. For example, for the official Google Maps Routes API Endpoint: "/directions/v2 : computeRoutes", although set correctly and accepted in the URL Path in Service Studio: the path is still being read in runtime as: "/directions/v2 %3A computeRoutes" by ODC/Outsystems 11. Current workaround works to explicitly decode the URL in the OnBeforeRequest: However, since the platform allows special chars in the URL path in a REST Action and doesn't complain or notify, it does not seem right and would make a better UX whilst saving time to another developers like me in future to figure out what's the issue, how to solve and then implement.

Just as all other elements, the custom exception could be public so that on consumer espaces you can have error handling for specific custom exceptions of the producer espaces. Showing what kind of exceptions are thrown in the tooltip of a user action would also be a good improvement

Most of the times I need to open Service Studio just to check code and I do not need to get the references. It would save a lot of time when we just want to check the code and not change anything

Currently each time a site property is saved, the new value is applied to the factory. This is separately done for each site property value that you adjust. In core modules applying the new setting can take some time. It would be nice if it is possible to change multiple site property values before applying the new settings to the whole environment.

Would be great to have a simple option to set the destination as a new tab rather than existing tab (maybe a dropdown as the image below). This is particularly useful in client actions, there are work arounds to solve this but require actions to check environment or current domain and these are always harcoded in some way.

Allow changing variable values while debugging

A native service studio plugin for Figma that doesn't just "import" but "links" components. Changing a padding value or a colour token in Figma should trigger a " suggested update" in Service Studio, allowing for" live code sync "between the design tool and the low- code IDE.

Currently, when using the Advanced SQL tool in OutSystems, developers are required to define an Output Structure even for SQL statements that do not return any data — such as INSERT, UPDATE, or DELETE queries. This mandatory output requirement introduces unnecessary steps in the development process. It creates confusion for beginners and adds extra overhead to simple operations that are not supposed to return results. Proposed Improvement: Introduce two different types of SQL tools to improve clarity and usability: ExecuteSQL_Select: for queries that return data (e.g., SELECT). ExecuteSQL_NonQuery: for queries that do not return data (e.g., INSERT, UPDATE, DELETE). ExecuteSQL_Scalar: for single-value queries (e.g., COUNT, MIN, MAX). These naming conventions are inspired by C# and other modern frameworks and would help improve developer efficiency and code readability. This change would eliminate the unnecessary requirement of defining output structures for non-query operations and streamline the development workflow.