Hello, community! 👋 Having worked with OutSystems over the past few years—surviving the nightmares of broken references and monolithic architectures in O11, and now exploring the isolation of microservices and the AI Agent Workbench in ODC—I started reflecting on the next evolutionary leap for our platform. OutSystems Mentor already helps us generate screens and initial logic from prompts, which is fantastic. But what about large-scale maintenance and refactoring? Our beloved TrueChange is brilliant at pointing out where the application broke. If I change the signature of a core Server Action (e.g., changing an Input from Text to a Record/Structure) or delete an attribute from an Entity, TrueChange turns everything red in the Consumers. But I still have to go into 20 different modules and fix the mapping manually. The missing feature today: TrueChange Auto-Healing (AI Semantic Refactoring) What if ODC integrated an AI engine directly into TrueChange that didn't just point out the error, but wrote the fix automatically for your review? How it would work in practice: The Trigger: You change the return of an API or the structure of an Entity in your Producer module. The Analysis: The AI Auto-Healing engine detects that 15 Consumer apps broke. Instead of just throwing errors, the AI analyzes the semantics of your change. The Action: The engine scans the Server Actions and Data Actions of the consumers and rewrites the mapping logic (adding Assigns, converting data types based on context, or modifying Aggregates). The Code Review: In ODC Studio, you get a "Pull Request" style notification. You see a visual diff (before/after) of the logic altered by the AI across all consumers, and you just click "Accept All" or reject and adjust it manually. This would transform the platform from "Low-Code" to "Zero-Maintenance Code" at the architecture layer.

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"

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.

when refactoring entities between espaces, manual database scripts are required to migrate data to the new physical entity

Currently in OutSystems Reactive , there is no native, straightforward way to render dynamic HTML content inside an Email Template. Expressions Escape Everything : The standard Expression widget in the Email editor automatically escapes all HTML tags, converting them to plain text. Missing Property : Unlike standard Reactive Web screens, the "Escape Content = No" property is missing from Expressions in the Email editor. No JavaScript Support : Emails are rendered server-side, so common web workarounds like using a JavaScript OnReady action to set innerHTML do not work in an email context. Container Limitations : Using a Container with an innerHTML attribute often results in empty content because the platform's internal email engine (similar to an internal GetEmailHtml method) frequently strips these attributes during generation for security reasons. OutSystems should implement one of the following to improve the developer experience: Enable " Escape Content = No": Add the same property found in standard web expressions to the Email Expression widget, allowing developers to pass sanitized HTML directly. Native HTML Widget for Emails : Enable the "HTML Element" widget within the Email UI Flow toolbox so developers can explicitly define HTML tags and inject attributes safely. Sanitized HTML Input : Provide a dedicated widget or property that specifically accepts the output of the SanitizeHtml action and renders it as formatted HTML in the final email body. Thanks, Ananth

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.

As we move toward Agentic AI in ODC, we are currently forced to choose between two paths for vector storage: External Vector DBs (Pinecone, Qdrant): Great performance, but introduces data residency/compliance hurdles for regulated industries. Native Workarounds: Storing vectors as JSON text in ODC Entities. I recently conducted a feasibility experiment to prove the "Native" path (storing vectors inside ODC to avoid external dependencies). You can see the architecture here: https://medium.com/@michael.de.guzman/proving-vector-storage-retrieval-inside-outsystems-developer-cloud-a89d8fb88661 The Problem: Currently, passing vector data between ODC and External Logic requires serializing arrays to JSON text. This introduces unnecessary overhead compared to passing native binary data. This creates a potential scalability bottleneck as dataset sizes grow. The Solution: Please introduce a Native Vector Data Type for ODC Entities and a built-in Vector_CosineSimilarity() server action (or Aggregate filter). The Benefit: This would allow ODC developers to build compliant, high-performance RAG and Agentic workflows entirely within the platform's trust boundary, without the massive overhead of JSON parsing.

Currently, if we define a Sorting by an attribute, that sorting becomes unresponsive after introducing a Group By in the aggregate, as the sorted attribute is no longer part of the aggregate output . This does not raise any errors or warnings in the TrueChange Tab or any signaling in the workspace. I find that this is an easily overlooked situation that can lead to unexpected behavior or inconsistent results. I suggest the implementation of a typical Outsystems background validation that triggers a warning (written on the TrueChange Tab and a visual cue on the aggregate) whenever the aggregate's sorting references attributes that are not part of the aggregate output after a Group By, ensuring consistency and preventing silent issues.

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.

 Current Context In the current version of Service Studio, all Local Variables share the same icon (a yellow square), regardless of their data type. The only visual indicator that a variable is a List is the small expansion arrow on the left or the naming convention chosen by the developer. This uniformity makes it difficult to instantly distinguish between a single record/primitive type and a collection of data. The Proposal I propose the introduction of a specific icon or visual badge for List-type variables. Instead of the standard square, a "stack" or "layers" icon should be used. This would allow developers to immediately identify that they are dealing with a collection, rather than a simple Text, Integer, Boolean, or Single Structure variable. Why is this important? Reduced Cognitive Load: Developers would no longer need to hover over or click a variable to confirm if it is a single record or a list. Identification becomes instantaneous. Error Prevention: It makes data mapping to widgets (such as Tables or Lists) and the use of "For Each" loops much more intuitive, preventing type mismatch confusion. Improved Code Legibility: Complex actions with numerous variables become significantly easier to scan visually, enhancing development speed and overall Developer Experience (DX). Suggested Visual Changes Simple Variables: Maintain the standard yellow square icon. List Variables: Use a "List" symbol (e.g., three stacked lines ≡) or add a small "stack/layers" badge overlaid on the existing icon.