Quite often, I am repeating the same set of joins in queries (both normal and advanced), that I would ordinarily put in a view. Think e.g. of a CRM system that regularly needs "all active clients" or an ordering system that needs "all open orders". Of course if you need just that, it's easy to put it in an action, but I often find myself needing the result and join that with some other tables. Unfortunately, for some reason OS does not allow to define database views, which imho is a great gap. Therefore, I'd really like to see support for database views or something similar (e.g. queries you can define on eSpace level and join the result of with another query, but that amounts to the same).

Hi,In Reactive Web Apps I've noticed that when navigating to public screens from other modules the transition is very slow - it shows a blank screen first, then it starts loading the screen and the CSS, causing a Flash of unstyled content.This takes about 2 to 4 seconds, making it a horrible experience.Upon further investigation, I've discovered that OutSystems is treating the navigation as a navigation to a totally different application, loading again all the necessary resources (JS, HTML, CSS). This is very atypical for a Single Page Application.This makes segregating front ends a major trade-off.Can this be improved?Thanks,Tiago

It would be highly beneficial if the Espace_Versions table included an additional column/attribute to store the publish/deployment comment that is currently supported through the recently added deployment comment option. Additionally, exposing the same information through the LifeTime APIs would greatly help customers build custom audit, monitoring, and deployment tracking solutions. This enhancement would provide better traceability of deployments, improve release governance, and help teams understand the intent/context behind each deployment without depending solely on external communication channels or manual documentation. Potential Use Cases: Custom deployment audit dashboards Release traceability and governance Tracking hotfix/business deployment reasons Displaying deployment comments in internal monitoring consoles Easier PROD publishes analysis and reporting Kind Regards, Sandeep

Hi, this is just an idea for a developer's perspective, it would be nice to have the ODC workflow builder in ODC Studio itself instead of going back and forth from ODC studio to ODC Portal when developing for the workflow.

Currently each time a site property is saved, the new value is applied to the factory. This is separately done for each site property value that you adjust. In core modules applying the new setting can take some time. It would be nice if it is possible to change multiple site property values before applying the new settings to the whole environment.

Sometimes I do development in my 4K monitor and its hard for me to do development in the studio because everything is small. If the studio has UI Scaling feature then I can scale the studio's UI to make it everything in the studio (texts & buttons) bigger

The default behaviour of datetime variables in Reactive apps is to convert from UTC to local time. This is a great in a lot of use cases, but hard to work with if a user want to see data in a different timezone.In this forum question , some 'hacks' are proposed:Use datetimes as textCompensate at server side for the difference in client timezoneThe prefered solution is to let developers set the config for this automatic conversion. The default behaviour to convert is good, but make an option to overwrite the default behaviour.

When compiling or publishing an application, it would be helpful if errors and warnings could be grouped by Screen, Block, or Action.

 Use-case: I have an app with many screens and tons of CSS classes defined in the style sheet; I decide I no longer need one or more screens, so I delete it/them; now, I have a bunch of CSS classes defined in the style sheet that are no longer used anywhere in the app. Problem: I don't want unused CCS classes in the style sheet, so now I'm forced to search for each class in the app to check if it's used or not before safely deleting its definition. Solution: there should be an easy way to "Removed All Unused CSS Definitions", just like there's a "Remove unused elements" (see image), and/or a visual cue on the Style Sheet, next to each unused CSS definition, to make it easy for thee developer to see that that particular definition is not being used (that way the developer can manually delete only the ones they're sure they'll never use again).

As OutSystems is moving away from providing licenses with unlimited ao's could we get the ao count for forge items listed in the forge?