To put it simply and directly: It would be great to be able to provide Mentor with a screenshot of a screen built in Figma. Who knows, maybe the Mentor can help create amazing projects with that.

OutSystems provides strong local debugging (breakpoints, step‑through execution) and logs, and in ODC it already supports distributed traces at a technical level. However, from a developer’s point of view, there is still a significant gap between raw observability data and actionable troubleshooting. I’m proposing a developer‑centric, end‑to‑end request trace experience that makes it easy to understand what happened for a single user action: from the UI event, through server logic, to database operations and external integrations, without manual correlation. Service Studio debugging works well within a module, but once a request crosses: UI → Server Actions Aggregates → Integrations Async flows / Timers developers must manually jump between: Debugger Logs Integration error screens External system logs This fragmentation slows down root‑cause analysis and increases support effort, especially for intermittent or environment‑specific issues. Logs show facts / data, but not context. Logs record events, but: Developers must manually infer which UI action triggered which server/integration call Correlating logs across layers requires custom correlation IDs or naming conventions Performance issues often require guesswork to identify the slow component Traces technically capture request lifecycles, but developers don’t yet have a single, intuitive “story view” of a request that ties everything together in a one‑click request trace view that: Starts from a user action (e.g., button click, screen load) Shows the full execution chain across: UI action Server actions Aggregates / queries Integration calls Async operations (where applicable) Presents timing, failures, and context in a single timeline This is not about adding more logs, but about connecting existing observability data into a developer‑friendly narrative.

In OutSystems Platform publishing is like comitting your changes to Version Management. It would be extremely helpful to be able to add comments on the 1 Click Publish process. This would be even more flexible if one could drill down these comments by changed object (webscreen, webblock, action, webreference action, etc)

As we are now having folders everywhere, please do the same for service studio main screen. This way applications can be grouped by context.

 The Problem Currently, the "Create Entity Actions Wrappers" (CRUD actions) feature in Service Studio follows a static, hard-coded template. While this is helpful for rapid prototyping, most professional enterprise projects require specific architectural patterns that the default scaffolding doesn’t support. As a result, developers must manually wrap every generated action to include: Audit Trails: Automatically filling CreatedBy or ChangedAt attributes. Standardized Exception Handling: Ensuring specific UI or Log messages are triggered. Validation Logic: Checking for business rules before execution. Naming Conventions: Adhering to specific project-wide naming standards for wrappers. This leads to a significant amount of repetitive, manual work every time a new entity is created, increasing the risk of human error and architectural inconsistency across the team. The Proposal The introduction of a Custom CRUD Pattern configuration within Service Studio (at the Application or Environment level). This feature would allow architects to define a "Blueprint" or "Template" for CRUD generation. When a developer right-clicks an entity and selects the option to generate actions, Service Studio would check for a defined custom pattern. If found, it would generate the actions based on that template instead of the default OutSystems standard. Key Capabilities: T emplate Definition : Define a standard flow for Create, Update, and Delete actions. For Validation actions as well, for example would automatically check if the mandatory attributes are not empty. Placeholder Support : Use variables for Entity names or attributes within the template. Boilerplate Logic : Automatically include logic like "GetUserId()" or "LogRecord" in every generated action. Architecture Alignment : Ensure all entities immediately follow the project's "Good Practices" without manual intervention. The Goal The goal is to move from "Standard Scaffolding" to "Architectural Scaffolding." This would significantly speed up the development of new entities, ensure the entire team follows the same patterns from day one, and reduce the technical debt caused by inconsistently wrapped CRUD Actions. Ultimately, both options would exist simultaneously. The idea is not to replace, but simply to add a new option.

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.

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?

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.

When working in environments with many apps and modules, finding the ones we use daily can take unnecessary time. It would be useful to have a "Mark as Favorite" option for modules in Service Studio. This would allow developers to quickly access their most frequently used modules when opening the environment. For example: A star icon next to the module name; A "Favorites" section on the home screen; A filter to show only favorite modules.

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.