I would like to see a built in midnight/dark theme for service studio. Something that is a little easier on the eyes when working the night shift.Looked around but couldn't find anything to suggest this is a duplicate, but let me know if it is.

While working in Service Studio using Dark Theme, selected elements such as Assigns, Decisions, Aggregates, Actions, Loops, and Connectors can be difficult to identify, especially when: Screen brightness is low. Working with large and complex logic flows. Presenting or sharing screens during meetings. Currently, the visual difference between selected and non-selected elements is quite subtle, making it challenging to quickly locate the active element and follow the execution flow. Suggestion: Introduce a High-Contrast Selection Border for selected elements. When a node or connector is selected, display a thicker, high-contrast border (for example, bright cyan, yellow, or orange) around the element. This would make the selected element immediately stand out from the surrounding workflow, improving visibility, reducing eye strain, and enhancing productivity when working in dark environments or on large server actions. This enhancement would significantly improve the overall usability and accessibility of Service Studio's Dark Theme experience.

The new 1-Click Publish With Message is a good idea, but to be useful, it needs improvements. 1. It should have the ability to hide the normal 1-Click Publish to force messages, or some other way to enforce this 2. The last message should automatically populate a new publish, or maybe a dropdown with the last 5 or so messages.

Hi OS team, can we also have a IntelliSense looks alike whenever we use alias in advance SQL can be helpful when too many join/sub queries sample auto popuplate from the user table currenly this is the behaviour whenever i use alias on my tables -no suggestion

An often-occuring issue is that user click on an action twice, which causes an action to run twice. This leads to very nasty issues where data is created and/or processed twice. One way to prevent this, is to wrap your Button into a 'Button Loading' widget, and adding an IsLoading widget to the page. It would be nice to support this in an easier way, either by: Adding a property to the button that adds 'IsLoading' behaviour to it Add ButtonLoading widgets around all your button widgets in your apps Any other ideas to achieve the same result?

Currently, when a mobile or reactive app client disconnects mid-request (e.g. user backgrounds the app, loses network, or a timeout occurs), OutSystems logs the following errors in Service Center as 500-level errors: "The client is disconnected because the underlying request has been completed. There is no longer an HttpContext available." "Failed to send request due to unexpected error" These errors are thrown deep in the ASP.NET/IIS pipeline by the ErrorNotifierModule, below the OutSystems application layer. This means developers have no way to catch or suppress them using OutSystems logic — not through OnException handlers, not through error handling in Client/Screen/Data Actions, and not through any pattern available in Service Studio. Why this is a problem: These errors are not actionable by developers — there is no OutSystems-level fix that prevents them They pollute the error log in Service Center, making it harder to identify real application errors (we currently have an average of 60.000 daily errors like these) They generate false alerts in monitoring tools and APM integrations that consume OutSystems error logs They cause unnecessary noise in production environments, particularly for mobile apps used on unreliable network connections What we are asking for: OutSystems R&D to implement one or both of the following: Suppress specific known client-disconnect exception types (e.g. HttpException with error code 0x800703E3) in the ErrorNotifierModule before they are written to the error log, since these represent expected network-level events, not application bugs Provide a configurable filter mechanism in Service Center or Factory Configuration that allows platform administrators to define error message patterns that should be downgraded (e.g. to a warning) or excluded from the error log entirely Expected outcome: Developers and operations teams can maintain clean, actionable error logs that reflect real application problems — without being forced to implement infrastructure-level workarounds outside the OutSystems platform.

Enable to Test an Action giving new input parameters.

Introduce a configuration mechanism that allows to enable or disable Code Quality analysis for specific applications and libraries. This capability would make it possible to exclude test applications, sandbox applications, or temporary applications, preventing them from affecting overall code quality metrics. With this configurable approach, we would gain greater control over which artifacts are included in quality measurements, ensuring that reports remain accurate, relevant, and focused on production-relevant systems.

Hi Outsystem Team, I believe that OutSystems Table Grid should also have some features like Data Grid such as column picker. Sometimes we have to use Data Grid just for the column picker type features. Thanks, Vijay M.

Full widespread support for null values, in all layers: database, actions, ...Not fake zeros disguised as nulls, but real thing, the ones that we can compare to is null. The ones that mean "I don't know the value for this... I don't even know if its zero"