Currently, ODC does not provide a mechanism to extract or automatically generate documentation for applications. In previous versions, such as OS11, tools like OutDoc and direct access to OutSystems metadata allowed teams to generate technical documentation more easily. The proposal is to introduce an AI-powered capability that can analyze an existing application or library within ODC and automatically generate technical documentation, such as: application architecture overview dependencies and libraries used module and component structure APIs and integrations main functional flows This feature would significantly reduce the manual effort required to create documentation, improve knowledge sharing across teams, and ensure that documentation remains up-to-date with the evolution of the codebase.

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

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.

Hi, ODC PE navigation and functionalities have bugs and logic isn't user friendly. 1.1. Cannot login with the username and password from the owner of the environment in an app. 1.2. Cannot edit created users or add a password to them. Name keeps as "Unnamed user". 1.3. Result: without proper setting up the users, we cannot use the apps that we test before implementing them in the client. 2. Remember Me in ODC login doesn't work. After several minutes we need to insert credentials again. 3. Login in ODC Studio should be available inside the app, without needing to do it in the browser. Browser login should act independently, specially if we want to login in apps with other users. 4. Make available Login action in server side so that a system user can be added 5. There isn't a button to open ODC Studio without opening an app. 6. Add more logs to the Logs, like we have in O11 Service Center. Just published an app and gave an error and nothing appear in the logs. We need to have more in-depth information in the logs. 7. Messages used in "LogMessage" action don't appear in the logs. 8. Add sort in apps in ODC for Created Date. 9. Add details in ODC in each functionality. 10. Add details in Platform Updates to know the impact of updating. Note: A Developer should have control at all times of what he is doing. For that, more information is needed and ODC doesn't provide enough control on performed actions or in logs. There are several O11 features that should be implemented in ODC. Simple is not always better, specially in an enterprise platform, as control should be the drive in this case.

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

Hi Outsystems Team, I'm currently facing an issue where Service Actions do not receive the full set of client cookies , while Server Actions do. This limitation prevents the use of HTTPRequestHandler.GetCookie / SetCookie inside Service Actions in real scenarios. 📌 Problem When a request reaches a Screen Action or Server Action, all browser cookies are forwarded to the action's execution context. However, when calling a Service Action, only a small subset of platform‑managed cookies (e.g., UserId, TenantId, etc.) is available. This means: Custom cookies created by the application never reach the Service Action. HTTPRequestHandler inside a Service Action cannot read or modify these cookies. Some patterns related to authentication, tracking, and user context become difficult or impossible. 🔍 Expected Behavior Ideally, a Service Action should be able to: Receive the same full cookie set that Server Actions receive. Support HTTPRequestHandler.GetCookie and SetCookie. Allow more advanced use cases such as: Authentication extensions Cross-app user context sharing Tracking / analytics A/B testing Custom session or preference handling 🎯 Why This Matters Many modern architectures rely on Service Actions as: Shared reusable service layers Abstraction layers across multiple applications Integration or cross‑module processing points Centralized logic for authentication, tracking, and user context Without access to client cookies, these Service Actions become: Harder to design Less reusable Less aligned with real-world requirements This directly affects large-scale multi-app environments. ❓ Questions for OutSystems Is there a recommended way to forward all cookies to a Service Actio Is this a platform limitation or an intentional design restriction? Is there any roadmap to allow Service Actions to access the full cookie context? For now, we rely on a Server Action to read the cookies and pass them as input parameters. Is there a better official workaround? 💡 Additional Notes We do not need to modify platform-managed cookie. We only need to access custom cookies generated by the application. Everything works perfectly in Server Actions — the limitation occurs only at the Service Action layer. 🙏 Conclusion I would like to propose a feature that allows Service Actions to: Receive all client cookies, or Optionally specify which custom cookies should be forwarded This would make Service Actions far more flexible and suitable for real-world multi-application use cases. Any insights, confirmations, or guidance from the community or OutSystems staff would be greatly appreciated. Thanks in advance!

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

In ODC it would be extremely valuable to have an official and supported way to perform direct queries against application databases in stages beyond Development. Currently, the only practical way to inspect database data is via ODC Studio in Development stage. Once the application is promoted to QA / Pre-Prod / Production, there is no official mechanism to query the database, even for simple troubleshooting or validation scenarios. This creates a real operational gap: In many cases, a simple SELECT query would immediately explain an issue. Instead, developers are forced to add temporary logging, deploy heavy diagnostic logic or reproduce issues back in Development (not always possible or effective). Adding logs purely for troubleshooting, increases noise in the code (lots of LogMessages) and often feels wrong when a safe DB query would solve the issue in minutes What would help: An official DB query tool for ODC Studio or ODC Portal feature for controlled data inspection with proper auditing, permissions, and safeguards. Why this is important: Modern cloud-native platforms rely heavily on observability and controlled introspection Troubleshooting issues in higher environments without DB visibility is unnecessarily hard This would significantly improve developer experience, support efficiency, and confidence in ODC Having an official, supported way to query stage databases in ODC would remove the need for workarounds and align ODC with real-world operational needs.

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.