Show who are the users online and currently working in this shared environmentThis future will be really useful to improve joint working culture.If the user is publishing then it will show their status as publishing.If they just working on it then it will show their status as online.If the user is not using the environment then it shows his status as Offline.It will help other users in the shared environment to avoid publishing at the same time.

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

When viewing data in a table add a default sort so that the last entries appear first.I believe most of the times the developers want to see the last inserted items in an entity.At least, when I do "View Data" I always end up adding the sort...Edit: It could be an option in Service Studio.

Having the possibility to remove the help from right click, because the help appears now in the same place that paste was before. So now I'm clicking it a lot of times :(This can be a option in settings, for example.

Introduce a unique icon for private actions in OutSystems to visually distinguish them from public actions. This improves clarity, reduces accidental misuse and supports better encapsulation of logic. A key benefit is that it eliminates the need to reorganize code into folders or rename actions. Observation: I could not find this exact idea already proposed. If anyone knows, please let me know. Attached a example.

When I was looking at the download page, I noticed two version naming systems are currently in use:For the IDE, on the downloads page we see the release "tag" (eg: "Development Environment 11 - Release 12").But then, on studio, we see the version number (eg, "11.0.406.0")Again, with platform server and lifetime this scenario repeats: on the download page the tag, on the software the version number. This creates a bit of confusion when one is trying to understand, e.g., which version of the platform server to download.By looking into this article detailing the version naming system and this article detailing the release lifecycle, one can reach the conclusion that the tag on the download page refers to the release life cycle ( the when ) and the version number details the type of changes on the release ( the what ).My suggestion is first and foremost to use a single naming system both on the software and the website, to avoid confusion. But going a little bit further, I would suggest adopting a simpler system where version number is based solely on the release (which in the end is the only thing the user cares about).  If as the article I previously linked suggests, there is predictability on the release cycle, then similarly to Ubtuntu, one can even make the date part of the versioning system, naming both the release and the version after the date, and if necessary, additional numbering for minor patches.Additionally, it would be really, really nice if we had exactly this page , but with the download links on the tables.Thank you for your time,Filipe

Hi,I believe that can be a good improvement to have the possibility to disable an REST/SOAP method from our exposed APIs.With that we can maintain versions with methods under work without the need to have different versions and, I believe it's more practical :)  (like the "disable" capacity in the action flows).The idea is to have them under the API but not available to use and not present in the generated documentation.Best regards,Ricardo Pereira

OutSystems now supports storing settings as secrets in both OutSystems 11 (Site Properties as Secrets) and OutSystems ODC. However, secrets often have an expiration date, and without proper tracking, they can expire unnoticed, causing disruptions. Proposed ideas : Optional Expiration Date for Secrets – Allow users to set an expiration date for secrets stored in Site Properties (OutSystems 11) and Secrets (OutSystems ODC). Reminder Notifications – Enable reminders to be sent before expiration to a specified role so they can take action. This feature would help OutSystems 11 / ODC users proactively manage secrets and avoid unexpected failures due to expired credentials.

It would be great if I could expand an assignment to some structure like is already possible for parameters of an action.

Builtin round function should enable one to indicate the round precision: Round(number, precision) where: Number is the value to round Precision: number of decimal places after round (if positive), number of position to the left side of the decimal separator where to round (if negative).