By default OutSystems parameters are by value, but there are few exceptions. These exceptions should be visible at Service Studio.Example currently:Following would be better, when actually it is by reference.

When you're working on the OS PaaS environment, the time that is displayed when a module is deployed is the server time. I would be nice to have a setting in lifetime where we can set our own timezone so for our company the correct time when an application is deployed is shown.In some cases we need to check when something was deployed and we need to 'calculate' when it was deployed. Als when people don't know it's a different timezone the will be some communication errors.It's that small thing that make life easier (-:

It would be great to have these events in a SOAP webservice also, so we could also manipulate Headers and RequestText of the SOAP Message.

When completing a Course, a wild quiz appears... I believe that if the number of questions and its complexity increases, the user acquires a bigger knowledge about the platform and its best practices.I would suggest that training official partners and MVPs group can help on that matter, making the community stronger in terms of knowledge.

This idea proposes a built-in visual tool that validates API requests and responses against their defined contracts, such as Swagger or OpenAPI specifications. The tool would automatically detect missing fields, incorrect data types, and deprecated attributes before or during runtime, helping developers catch integration issues early. By making API contract validation visible and easy to understand within OutSystems, teams can reduce production defects and integration failures without relying on external tools or manual testing.

It would be great to have the possibility to comment on a group of elements.And make it visually clear in the interface, which elements the comment effects.In this way it's more clear which elements are part of the comment and as a bonus you can easier comment on large pieces of code.In the same way comments are usually done in traditional coding, like (e.g. in javascript): //Start of function / piece of code /* Initialize and invoke a the greetUser function to assign user's name to a constant and print out a greeting. */ function   greetUser () {     const name = prompt("What is your name?");     console.log("Hello ," + name + "! How are you?"); } greetUser(); //Start of another function / piece of code /* Initialize and invoke a the sayGoodbyeUser function to print out a goodbye. */ ......Visual idea:

The main idea is simple:- You could limit the modules that consume this module, this would mean that no modules outside that set of modules could ever reference anything from this module.This means the module owner(s) can in effect limit the consumers modules.I believe this would greatly help some medium/big factories.

There should be a functionality in which if we add locale and select language we want to translate can automatically translate original text to translate text without filling 'Translation in' column. That is we don'n need to translate any text , it will automatically detect all texts and show the translation according to the languages provided in the outsystems. thanks..

 Description : On the Asset Moderation History page, it would be extremely helpful to have Edit and Delete buttons for user comments. Currently, if a user accidentally submits a comment multiple times, such as due to button loading delays or double-clicks, there is no way to either delete the duplicate or update the text. Use Case Example : I recently experienced this issue where, due to a slight UI lag, I unintentionally clicked the "Comment" button twice in the Add Comment PopUp. The same comment was added twice to the moderation history. Unfortunately, I wasn't able to delete the extra comment or update it with corrected or different information. This can lead to confusion or clutter in the comment history. Proposed Solution : Add Edit and Delete buttons for each comment in the Asset Moderation History list. Ensure appropriate permissions or audit trail is maintained to preserve moderation integrity. This enhancement will improve user experience and data cleanliness in moderation workflows.

The scenario is an attribute that is decided not be used anymore in an entity, but its deletion is not a good policy at that point.The only way to "deprecate" is adding a comment in the description, which is not a safe solution because it doesn't prevent developers to keep using it.So there could be a property in the attribute (called Deprecated) that could grey out the field and warn about its usage in SQLs and other actions.