Hey guys,I think it would be really helpful to have a new tab besides the TrueChange tab that shows the Architecture Dashboard report for the specific module we're seeing.Apart from being more accessible, developers can easily look at the report in the module scope and more proactively reduce technical debt.

The current Community platform suffers from performance limitations and provides a restricted level of user interactivity. To improve the overall user experience, I propose migrating the Community to a Reactive Web architecture within OutSystems. The growth and increased user engagement in the OutSystems Community can be attributed to a more intuitive, faster, and interactive experience that encourages users to actively participate, share knowledge, and return to the platform more frequently. Let’s move forward with this improvement to unlock a faster, more engaging, and truly collaborative community experience for all users. This is a developer’s observation based on system usage and user experience.

So the openapi specification that is found in the documentation of the ODC Rest APIs has the openapi version set to 3.0.4. However, if you feed it as input to consume in ODC Studio, only versions up to 3.0.3 are supported. Anything higher is (currently) just refused. it returns the very meaningful message that the format is not recognized. (for which i'll make another idea) So why not keep these 2 in line, and only put versions in the documentation when they are also supported in ODC Studio?

Aggregate should have an option to remove duplicates. I see this as a new tab like "Sorting" where you could select the column you want to remove duplicates.

 The Problem Most OutSystems developers learn best practices by reading documentation or watching tutorials. That's fine, but there's a gap between knowing what best practices are and actually applying them under pressure on real code. There's no structured, hands-on way to practice refactoring, security hardening, or architecture fixes within the OutSystems ecosystem. You either learn on production apps (risky) or you don't get to practice at all. The Idea Extend AI Mentor to include a "Practice Mode", a generator that deliberately creates imperfect OutSystems applications for developers to find and fix. AI Mentor already understands OutSystems best practices deeply. The idea is to flip that knowledge: instead of pointing out what's wrong in your app, it builds a training app that already has the problems baked in, and challenges the developer to find and resolve them. This is not about AI completing the work. It's about AI leaving the right kind of mess, on purpose. How It Works — Three Stages Stage 1 — Foundations (5 issues) Easiest tier. Designed for developers new to OutSystems best practices. Typical issues: unused variables, missing indexes on foreign keys, hardcoded values that should be site properties, public actions that should be internal, missing NullIdentifier() checks. Stage 2 — Intermediate (10 issues) Mid-tier. Developers need to think about architecture and maintainability. Typical issues: logic inside Preparation that belongs in a Server Action, missing input validation, exposed sensitive data in REST APIs, poor naming conventions, N+1 query patterns, missing error handling in integrations. Stage 3 — Advanced (15–20 issues) Senior-level challenge. Security, performance, and architectural decisions. Typical issues: SQL injection surface areas, missing role checks on screens and actions, exposed system entities, broken session handling, unoptimized aggregate fetching, tight coupling between modules, missing audit trail logic, improper use of client-side vs server-side logic (maybe bpt and tenant optimization and error handling too). Goal is simple do that changes remove error, remove warning and publish the application. Why This Works The value isn't in the generated app itself — it's in the deliberate, structured imperfection. Developers get a realistic codebase with real OutSystems patterns, real module structures, and real antipatterns to hunt down. AI Mentor can then serve as the referee: once the developer believes they've fixed the issues, AI Mentor reviews the app and confirms whether each problem has been correctly resolved — closing the feedback loop without giving away the answers upfront. Expected Outcomes - Developers build muscle memory for catching common OutSystems antipatterns - Junior developers have a safe, structured environment to level up - Teams can use Stage 3 as a pre-promotion or onboarding assessment - OutSystems certifications could eventually reference this as a practical preparation tool Summary AI Mentor already knows everything that's wrong with your app. Let it build an app that's wrong on purpose — and teach developers by making them fix it. Stage 1: find 5. Stage 2: find 10. Stage 3: find 15–20. Learn by doing, not by reading.

I think it would be great if there were a way to point co-workers to a specific part of the code, for example as Architecture Dashboard does. This would be super helpful to have because we could show directly what part of the code we are talking about with a co-worker.

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.

Hello @OutSystems Community. When we create an OutSystems Support case we are not always aware of its importance. My idea is to allow the possibility of clicking on the Tag with the severity of Issue (level of difficulty) of Support Case resolution for example "Normal" to "High" to open a popup with the possibility of changing the level of difficulty of the ticket. This idea is also in order to help the OutSystems Support team to better track the degree of demand that the resolution of each support case may require. Best Regards, Paulo Russo .

Hello, It's completely fundamental to have a way/tool to migrate App/modules from Reactive to ODC. Right now it's a big bottleneck as we can't open modules created in Service Studio in ODC studio. Will be impossible to convince customers to migrate Apps from Reactive to ODC if the process is no simple and quite fast. Thanks, Paulo Torres

There is a limitation in mapping two structures with different types and one element is a list of any type. Service Studio doesn't shows the mapping function.We're only able to Map 1 level, as shown in the example below:The mapping should also work for inner lists elements of a structure.