It would be great if OutSystems exposed REST APIs supported multiple response types, instead of just one type (structure).In swagger, you can set a response type for each status code and have different structures for each one and all the different outputs are then properly documented.Something like this:responses:        200:          description: An array of products          schema:            type: array            items:              $ref: '#/definitions/Product'        default:          description: Unexpected error          schema:            $ref: '#/definitions/Error'This would give:- more flexibility when creating exposed REST APIs;- multiple response types support in the "OutSystems way";- better documentation, including all the response types available;

Hello there,It would be nice to have inside Service Studio a way that we could check inside the module what size does it actually occupies each Flow, Server Actions, All the images all at once, etc...Best Regards,Edgar Ramos

A significant security and GDPR compliance requirement is being able to automatically disable accounts when staff leave the firm or a team.  Whilst we can build applications in OutSystems with various authentication options the only external authentication method available for the developer environment is adfs. Given the wide use of platforms such as OKTA for synchronising and managing cloud accounts it would be great if the OutSystems platform itself supported SAML2.0 and/or OIDC.

Recently, a requirement forced me to use a Data action to fetch data from an external database.In Reactive, this means the Start Index is not available as a parameter, which means implementing pagination requires 10 times more work than a regular aggregate.The problem and solution are clearly explained in this forum post .It feels like there should be a more immediate way to do this, since OutSystems is pushing Reactive Web as the future, and integration with external databases as one of its main selling points.Thank you

The new Data Grid is fantastic, but the fact that you have to add an ActionColumn and that that is the only one that can have an OnClick handler attached is quite limiting. It would be very nice to have the option to do the following:1. Add an OnClick handler to each column regardless of type2.Add an OnClick to an entire row so that they can click on any column and it triggers the handlerI would suggest that the Cell OnClick overrides the row one... but the individual cells click probably more important. Or potentially just allow one or the other.

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.

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 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.

It is great that the OutSystems demo Homebanking apps are multilingual and also available in German. Nevertheless it is obvious the translation was not done by a German native speaker. In this way it is - to be honest - a little bit funny, instead of being a serious business app. E. g. the credit card VISA was translated as Visum in German language, which only means a visa for a country, not the credit card. And a lot of other stuff. English name -> curent translation - suggested translation Visa -> Visum -> Visa (I think it the same for the Portuguese word here: Visto) Home -> Heim -> Startseite Balance -> Gleichgewicht -> Kontostand Amount -> Menge -> Betrag Continue -> Weitermachen -> Weiter Loans -> Loans -> Kredite View -> Sicht -> Überblick Share Receipt -> Aktienquittung -> Quittung It would be great if these Homebanking apps (maybe others also) could be checked by a native German speaking OutSystems employee of the DACH-region.

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.