I would like to be able to use HTML content in the email body in Reactive apps.Html content is needed to sent emails with a nice layout from Reactive apps.Expressions in Traditional Applications have the "Escape Content" attribute. When you set it to "No" a mail sent by a Traditional Application is delivered as a HTML Document. This is not possible in Reactive applications.The HTML Element can also not be used in an email in Reactive app.The only current solution would be, to create a Traditional Application just for sending the email and provide a public EmailSend-Method. But that is a lot of overhead just to send a mail.

I was searching for this feature in the ideas, but I couldn't find it. It would be useful to be able to save a comment in the service center (not only in service studio) in case there is a need to update something that was typed incorrectly, for instance or missing relevant info. I think it would also be of value to display the user who did it and the timestamp.

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.

It would be nice to have an option to clone/duplicate an application in Service Studio in the application detail view like we have the option to edit and remove.And also it would be nice to have the option to do the same to the modules inside but as an option.

Service Studio should have new, separate "Tests" tab.This would enable integrating tests to any eSpace and would minimize required overhead for testing any action, including private actions.Why?Testing your code is more professional than not testing.Unit testing should be minimal extra effort for developer, because otherwise tests are usually not done.Publishing new code could be controlled - you cannot publish untested code, or code which has some failing tests, for example.Test code should never go to Production environment.Testing is good.How?Tests are integrated to eSpace/module oml file.During code generation process, actions from "Tests" tab would create a separate .NET project and this project would be a friend assembly (internalsVisibleTo attributes configured) for main project to compile.1-Click Publish deployments with tests could start from (currently underused?) personal area (or another IIS folder), where tests would be run.Depending on how tests go and how is decided in additional configuration, deployment would continue to Public area or show an error in Service studio.This way, creating unit tests would be as effortless as when creating unit tests in any other modern programming language - just few clicks away. There could be also accelerators to generate unit test actions or "system events" to initialize/teardown test runs.Currently, writing any tests to private actions is also either impossible or exposing some unwanted/test related code to production environments.It's a big change, but from discussions with makers/experts @ ODC I've learned this should not be too far-fetched idea to implement. Maybe for P12, please?Another, possibly the simplest way to enable testing / production code separation without massive modifications to existing compiling process could be a capability to define another espace as " friend " espace. This per-espace setting could reveal internal (=OS private) actions to the another espace marked as a friend and thus enable referencing these otherwise out-of-the scope actions for testing purposes.If done like this, feature could be achieved using small amounts of .NET reflection trickery or previously suggested InternalsVisibleTo attribute (that has been around since 2002 release of .NET 2.0).Security-wise, there should be no problems either, (albeit a bit more work during compilation) as friend assemblies can be defined as signed assemblies, too.Personal opinion, but this topic is really heavily connected with OS small book #2, #5 and #7.

 Problem Development teams often work across different geographical locations and time zones, while the OutSystems environment is typically configured with a different server time zone (for example, UTC or a customer-specific time zone). When reviewing timers, scheduler executions, logs, deployments, or other time-based activities in Service Center, users must manually calculate the current server date and time using external tools or time zone converters. This is inconvenient and can lead to confusion when validating whether a timer has executed or when correlating log timestamps. Proposed Solution Display the current server date and time prominently within Service Center (for example, in the header or footer). The display should automatically reflect the environment's configured time zone and optionally show the time zone abbreviation. Example: Server Date & Time: 10 Jul 2026, 14:35:42 UTC Benefits Eliminates the need to manually convert server time across different time zones. Makes it easier to verify timer executions and scheduler runs. Simplifies troubleshooting, deployments, and log analysis. Reduces errors caused by time zone differences. Improves productivity for developers, architects, tech leads, and support teams working across multiple regions. This small enhancement would provide immediate visibility into the server's current date and time, making Service Center more efficient for day-to-day monitoring and troubleshooting.

 To be able to set conditional breakpoints instead of breaking everytime.

Would be a (minor) quality of life feature if you could bind a label to an input if you simply drag and drop it from the tool box on the left straight on the Input widget. For example here, this widget is bound to a "Max records" local variable, to control how many records an aggregate returns. If I drag the label on to it, it could do several things: Add the label on top of the Input Set the Input Widget automatically on the Label properties, and give it a name like "InputName_Label" Set the text for the label on a 'best guess' case, depending on what the input is bound to (for example here, Max records) This could work for all other input type widgets: text area, switches, checkboxes, dropdowns, etc.

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.

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.