I would like Service Studio to automatically add code to the assignment after I have named it in this specific way:[NameOfAnInernalVariable]++Obviously, the automatically added code should be:NameOfAnInernalVariable = NameOfAnInernalVariable + 1Perhaps it would also make sense to do this for types other than int - example:NameOfAnInernalVariable  = AddDays(NameOfAnInernalVariable, 1)Although technically simple, this behaviour would save me a lot of time when developing.

Dear Team, I would like to propose an enhancement to the current table functionality. Similar to the features available in DataGrid, it would be beneficial to introduce the ability to: Reorder table columns. Hide or unhide specific columns as required. These capabilities are particularly important in reconciliation processes, where users often need flexibility to customize views for efficient comparison and analysis. I believe this improvement would significantly enhance usability and provide a more seamless user experience. Thank you for your consideration.

Collation is a problem in sorting when you have characters like "ÅÄÖ". Those are sorted incorrectly.Platform thinks that those ÅÄ = A and Ö = O , but that is wrong. Those should be after Z ....TUVWXYZ ÅÄÖIdea how to fix this:possibility to set collation in lifetime on platform level (this sets platform default level collation)possibility to set collation in application (module properties > overwrites platform level collation)When user sets collation either ways, platform adds automatically database searches  (SQLs + aggregates) COLLATE clause after TEXT attributes.Maybe add possibility to remove use of it in aggregates (checkbox: use collation [x]).SELECT {Sorting}.* FROM {Sorting} WHERE {Sorting}.[Sortedcolumn] LIKE '%'+ @SearchString + '%' COLLATE Finnish_Swedish_CI_AS ORDER BY @TableSort COLLATE Finnish_Swedish_CI_ASAnother possibility is to set collation on server or directly database, but this is probably not possible in AWS? See community discussion and current workaround: https://www.outsystems.com/forums/discussion/63776/incorrect-sorting-of-scandinavian-characters/#

I recently noticed that LinkedIn does not include "OutSystems Developer" as a job title option in its database. As someone who works in this field, I believe it would be beneficial to have this title available for professionals to select and display on their profiles. It would not only increase visibility for the platform, but it would also help to establish OutSystems as a recognized and valued skillset in the job market.I would like to suggest that the OutSystems team reach out to the LinkedIn product team and request that they add "OutSystems Developer" to their job title list. I believe this would be a valuable addition to both platforms and would greatly benefit professionals working with OutSystems.

When the timepicker renders, it inherits the current page locale. However, when the locale changes, the timepicker does not change its locale with it. But keep the locale it has when it rendered. Here are some examples: English to Arabic The screen renders with English locale. The timepicker uses 12-hour clock symbols of "AM" & "PM". But when the locale changes to Arabic, instead of using "ص" & "م", it is still using "AM" & "PM". Arabic to English Same issue can be detected in the reverse scenario. The timepicker keeps using "ص" & "م", as it rendered when the locale of the page was Arabic.

Timepicker aligns it self a the left side of the input when the page direction is left-to-right. However, it is still aligned to left, in page with direction right-to-left. If it follow the same patterns, it should be aligned to the right side of the input. Left-to-right Right-to-left

The server seems to be storing all date/time in UTC format. However while reading the errors/logs and other details in Service Center, the UTC format makes it difficult to comprehend (if the user is in different timezone than UTC). May be we can convert to user's local timezone and display the date (how it happens in react client side).

Description: Currently, Outsystems supports the use of Mobile Screens for Progressive Web Applications (PWAs). However, there is a growing need to enable Web Screens for PWA development as well. In our case, many of our applications are deployed in environments with intermittent or no internet connectivity, such as ships operating globally. These use cases require the ability to run web applications in offline mode, which PWAs can effectively provide. While it is possible to run PWAs using mobile screens, the mobile layout and design constraints make it difficult to implement complex interfaces intended for web use. Designing and maintaining a web-like experience within mobile screen constraints in Service Studio is cumbersome and limits development efficiency and user experience. Proposed Enhancement: Allow developers to create and deploy PWAs using Web Screens in addition to Mobile Screens, enabling full offline capability and a more flexible design experience suitable for desktop or large-screen use cases. Expected Benefits: Improved developer productivity by allowing use of standard web screen design and layout tools. Enhanced user experience for large-screen devices and web-based offline scenarios. Broader applicability of Outsystems PWAs across industries requiring offline access, including maritime, logistics, and remote operations for Laptop/Computer devices

A propose a public bug tracker for issues in the OutSystems platform. I understand why OutSystems would be reluctant to do this but here's some advantages: Transparency : a public bug tracker shows commitment to transparency and accountability, building trust with the community and customers. Community Collaboration : it allows users to report bugs, suggest fixes, and contribute to the platform's development. Improved Communication: users get visibility into the status of reported bugs, avoiding redundant reports. Prioritization by Demand : users can vote on issues they care about most, helping OutSystems prioritize fixes based on real-world demand. Knowledge Sharing : a public bug tracker serves as a centralized knowledge base where users can search for known issues and workarounds. ( Disclaimer: an LLM did help me write some of this ) The motivation of this idea comes from the time wasted recently creating support cases for problems that were already identified by the OutSystems team. Many of these problems have forum posts with dead ends, where people were left without an answer. I would imagine this would also free up time from the support team. Cheers, Tiago

Able to bookmark Documentation, Tech Talk, Dev zone Articles under My Profile.