It would be relevant for us to be able to manage our certificates, to be able to remove expired ones to avoid conflicts on the platform, and to be able to renew certificates when emergencies arise. Having a view of our certificates without having to open tickets, and we end up wasting time trying to understand the problems, however I emphasize that the OutSystems team is 5-star. Or a lifetime option for access this information.

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 know, contact centres are underwater everywhere (as SNS24 in Portugal).The idea is to create a chatbot for FAQs that allow people to quickly get relevant information.We can use OutSystems.AI chatbot , integrated with the QnA service and integrated with some oficial knowledge bases (example: https://www.ecdc.europa.eu/en/novel-coronavirus-china/questions-answers ).Unanswered questions can be listed in a page, to be reviewed and added to the knowledge base, to make the chatbot smarter and smarter.The chatbot could then be highly improved if we allow humans to enter the loop and make the experience even smoother.

Please add a native, fully supported platform feature to move an entity from one module to another without losing data. This feature should preserve primary keys, foreign keys, references, and runtime data, and it should update dependencies safely across producer and consumer modules. It should also support impact analysis and validation before applying the change, so teams can refactor module boundaries with confidence.

In any modules, the paste option is not working or you can say its disabled in few places and its not working on the find and replace dialogue box, i need to type manually everytime in this new update.

I would be great to be able to edit entity data (in addition to the ViewData functionality) inside Service Studio.As far as I know, there is no easy way to manually edit data for testing purposes.This is extremely helpful especially when bootstrapping data from Excel

 Challenge: Currently, widgets in Service Studio don't have names by default. Developers typically only assign names when they need to manipulate widgets in business logic. However, widget names are essential for test automation because when a name is defined, the generated HTML element ID includes a static part (based on the widget name) alongside the dynamic part. This static portion can be used as a reliable selector in test scripts. Without named widgets, HTML element IDs are entirely dynamic, making test automation scripts fragile and prone to breaking whenever screen changes are made. This forces QA teams to constantly update test selectors. Proposed Solution: Auto-generate unique default names for widgets within each screen (e.g., Button1, Button2, Input1, Table1). This would: Provide stable HTML element IDs for test automation without requiring manual developer effort Make test scripts more robust and maintainable Reduce the time spent fixing broken tests after UI changes Improve overall application testability out-of-the-box Trade-offs: This would make the HTML slightly more verbose, but the impact would be minimal compared to the significant benefits for test automation and quality assurance workflows.

In Reactive Web applications, it is common to have multiple front-end modules within the same application. Currently, Client Variables are scoped to a single module, which creates challenges when we need to share session-like data across modules. A common workaround is to centralize these variables in one module (_CW) and expose them through public client actions. While this approach works, it introduces some limitations: It increases complexity It requires additional control over events to retrieve the variable It cannot be used in Aggregates or Data Actions, since client actions are not supported in those contexts, even though module-level client variables are My suggestion is to introduce the ability to mark Client Variables as "Public", allowing them to be accessed across modules via references, similar to how public elements (e.g., actions, structures) are exposed today. This would enable: Direct access to shared client state across modules Cleaner and more maintainable reuse Elimination of unnecessary client actions and events used to retrieve values Consistent usage of client variables in UI logic and data-fetching layers This improvement would simplify cross-module state management and reduce the need for workarounds, especially in larger applications with multiple front-end modules.

 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.

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