In multiple enterprise conversations, a recurring concern I encounter is around long-term platform dependency and source code ownership. Prospective clients often ask whether, in a worst-case scenario or strategic pivot, they would have the ability to access and operationalize their application source code independently of the platform. To address this more effectively during pre-sales and architecture discussions, it would be extremely valuable to have a feature in the trial or demo environment that allows export of the application source code in a structured .NET format that can be deployed in a standard .NET setup. Having the ability to demonstrate this live would: Instantly reduce perceived vendor lock-in concerns Increase architectural confidence among CTOs and enterprise architects Accelerate decision cycles during evaluation Strengthen positioning against traditional custom development arguments In many cases, the hesitation is not about capability; it is about control and reversibility. If we can showcase that portability exists in a tangible way, it materially improves conversion confidence. This capability would significantly enhance enterprise adoption conversations.

OutSystems did an awesome job with redesigning the icon system which is used in the Hybrid version of Service Studio.However I think some icon designs got worse, mostly noted the input and output parameter icons:In the old design the arrow in and out are very clearIn the new design:Regards,Daniel

Sometimes we launch a deployment, you go back the next day thinking the teams have the new features on the target enviroment and... sorprise! it´s sttoped waiting for confirmation for the impact on running business processes, and loose several hours for the deployment start and finish. Also, if you have two steps, this question it´s asking two times! (if always review on stage 2, please, don´t ask on stage 1). Something than could be ideal for us if you have a parameter to say if you want to ask or not the impact on the running business processes so the LT don´t ask and continue with the deployment (something that works as deployment in two stages, that you can decide in wich enviroments you want to ask or not).

While consuming any rest API with null value fields, platform discard those fields from the output of that API. So instead of discarding those we can consume those as text and show message that your null values fields are created as text. Thanks.

An integrated " AI Audit Trail ." that attaches the original natural language prompts and business requirements to every generated element. This would allow the architect to click any logic node and see the" intent history," helping to debug AI " hallucinations" in complex business rules.

With multilingual in a web or mobile project , it is necessary to show dates in the respective languages.The idea would be to have an extra field in the FormatDateTime function that would allow you to receive the location and return the formatted translated date.All the Locales would be expressed according to the RFC 1766 standard format.Examples:In English (default): Friday, 08 november, 2019In Dutch: Vrijdag, 08 november, 2019In French: Vendredi, 08 novembre, 2019In Spanish: Viernes, 08 noviembre, 2019

If we can enable a holiday period for our personal environment, it can save us trouble and inconvenience of having our apps deleted. Thou to ensure this is not being abused, when we set the holiday, there must be a start and end date. And maybe some validations, eg not more than 2 months etc...so that we will not be able to set for 1 year or something. Of course, the time period, will not be able to please everybody. Then after this holiday period ended, the existing control can comes in, eg. if not logged in for 2 weeks, then deactivated and eventually removed Think this is good, as I sometimes do go on a slightly lesser than 1 month holiday, and will not be able to log in.

Hello Guys,It would be great if solution publish process could be enhanced to be faster. Our project has many modules and takes longer than we require in our continuous integration process to publish a solution.Just to give a bit of context with an example - in our daily continuous integration process, we publish a solution against our DEV environment and, if everything goes well, we push it to the next environment for next day QA testing. The issue we face is that with the time it takes, if anything goes wrong with either of these solution publishes, we can have a hard time to react on time to fix the problem and to try again, on the same day.

Just like Service Studio, it would be great to have an auto-update feature in Integration Studio as well. This would streamline the upgrade process and ensure consistency across tools.

The new DatePicker  of OutSystems UI, based on flatpickr library, contrary to the old one that is now named DEPRECATED_DatePicker, based in pikaday library, doesn't allow the user to enter a date in the input by typing directly on it  via a widget configuration, which makes it harder to allow that behavior.With this idea I would like to propose to OutSystems that an option is added in the DatePicker_OptionalConfigs structure, an input of the widget, to enable this behavior.The flatpickr library which the new component is based on already allows such a configuration but i's not exposed by the OutSystems UI webblock.Another alternative would be  allowing the developers to extended the widget capabilities by providing an open input (that would receive a JSON) like the old DatePicker used to do. The current approach limits the extensibility of the component and this idea is the only way to improve and extended the component.Below was the approach to enable more functionalities of the underlying library.I understand the expected functionality is possible with the use of a client action that enables the behavior but it requires additional overhead for development. It needs an initialize action for every instance of the component with the required config. With this ideia I challenge the current implementation to improve development experience.Please consider these options and allow the developers to extended the libraries.