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.

To add a link or a way to quickly open the Event Handler Action from Properties / Events of UI Widget. This can be extended to On After Fetch of Fetch Data From Server or UI Aggregrate. This will improve the developer experience to quickly open the Client/ Screen Action that assigned as Event Handler or After Fetch Event rather than scroll up and down Elements Tree For Button and link, we can quickly double click the Element in the canvas to quickly access the OnClick Event Handler already, however, this should be good if there's a similar way for other Widget like Dropdown, Switch, Custom WebBlock with Events, Data Fetch Aggregate...

 Problem Debugging layout issues in Reactive Web apps can be time-consuming. Developers often need to inspect CSS, containers, flex behavior, spacing, width, and alignment directly in the browser, but Service Studio does not provide a clear visual way to understand why a layout is breaking. How this suggestion can help A built-in Layout Inspector would help developers quickly identify spacing, alignment, overflow, flex/grid behavior, and responsive issues without switching constantly between Service Studio and browser DevTools. Implementation example Add a right-click option on widgets: Inspect Layout It could show: Widget: Container_Main Display: Flex Direction: Row Gap: 16px Width: 100% Padding: 24px Overflow: Hidden Parent Container: Section_Content It could also highlight margins, padding, and parent-child relationships visually inside Service Studio.

Mentor is outstanding for developing components when you can explain your vision with language — although at times an image truly conveys more than words. His works well for pictures of current user interfaces (from other apps, or even other parts of your own app), images of whiteboard drawings, or any additional visual aid. That translation step is where things get lost. The idea is let us submit a photo alongside the Mentor chat, and give Mentor the task to examine it and generate the OutSystems component that matches it. This would work for captures of current user interfaces (from other apps, or even other parts of your own app), photos of whiteboard sketches, or any other pictorial reference. The value here is huge for teams that work fast. Instead of taking time writing detailed prompts, you just insert a screenshot and let Mentor figure it out. This might turn Mentor effectively advantageous for a wider range of daily development scenarios, beyond merely assisting people experienced in formulating prompts.

Maintaining accurate, up-to-date documentation remains a challenge in enterprise environments — especially as applications evolve and team members change. While tools such as OutDoc provide valuable metadata-based documentation (e.g., structural elements, entities, modules, dependencies), there is an opportunity to extend documentation capabilities further using AI within the platform itself. I would like to propose native AI-generated documentation that goes beyond structural metadata and instead leverages the platform’s understanding of: Application logic flows Business rules and decision paths Integration intent and usage patterns Architectural layering Cross-module interactions Rather than simply listing components, the AI could generate contextual explanations such as: What the application does functionally How key processes are orchestrated Which integrations are critical and why How data flows across modules Where architectural boundaries exist This could live within the application overview, Service Studio, or a dedicated Documentation view — refreshable on demand and editable as needed. Importantly, this would add value not only for future platform directions, but also for the large base of existing OutSystems 11 (O11) applications running in production today. Documentation drift and knowledge loss are challenges that exist now, and having AI-assisted documentation available in O11 would provide immediate impact for enterprise teams. Many teams already experiment with exporting artifacts and using external AI tools to generate higher-level documentation. I recently explored this approach externally as a proof of concept: 👉 https://www.acceleratedfocus.com/post/bringing-clarity-to-undocumented-outsystems-code-with-ai Embedding this capability directly into the platform would: Improve developer onboarding Reduce knowledge loss Support governance and compliance Accelerate modernization initiatives Strengthen long-term maintainability This would not replace structured metadata documentation tools like OutDoc, but would complement them with AI-driven contextual understanding.

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?

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.

 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.

Forge is the lifeblood of OutSystems. All great platforms eventually realize the need for something like it: a mechanism that allows the ecosystem to grow beyond internal contributions alone. It is the mark of a mature system, and Forge is a genuinely impressive manifestation of that idea. The most critical component of any such system is giving credit where credit is due. Without a strong feedback loop between contributors and the value they receive in return, the whole thing starts to break down. Contributions are wholly dependent on that loop. If there is not enough incentive on one side of the equation, the system can no longer self-sustain. This is not a minor inconvenience; it threatens the health of the entire ecosystem. It thrives on symbiosis. To be honest, I am surprised (as a relative newcomer to OutSystems) that the system is as strong as it is. On first glance, the incentives are fairly weak. There is an inherent imbalance between the effort required to build and submit quality Forge contributions and what those contributors stand to gain. That the ecosystem works as well as it does reflects a community that has achieved something genuinely rare. I want to make that point concrete: somehow, the OutSystems community has accomplished what others in similar spaces could not. I would chalk it up to a large, motivated developer base that may sometimes be frustrated, but is ultimately a great collection of individuals focused on advancing the platform for their fellow developers. It is a real feat, and it deserves to be celebrated. But as they say, it is not all unicorns and rainbows. The ongoing challenge is sustaining what is already out of balance. Developer contributions are not adequately incentivized, and ODC has made this worse, not better. OutSystems contributions seem to be increasingly privatized. What may have once been public and GitHub-facing is no longer possible. In my (admittedly short) time as an OutSystems developer, working exclusively in ODC, my contributions are siloed. Traditionally, I would have a GitHub repo that speaks to my work, serves as a portfolio, and acts as the natural payoff for open-source and free-source contributions. That was the incentive. That was the feedback loop closing. With ODC, that loop is broken. My contributions are contained and constricted within the OutSystems ecosystem. No GitHub repo. Nothing I own or control. Everything is increasingly containerized in constructs that only exist within this platform. If I were a top contributor here, I would only be a top contributor here. My work no longer reflects what I am capable of as a developer broadly; it only reflects what I am capable of as an "OutSystems Developer." Those two things are not synonymous, and I think there are a lot of talented OutSystems developers who deserve to stand strongly as developers, full stop. I will give credit where credit is due: this approach is sticky for OutSystems, and the one-sided benefit is strong. Well done. But the problem is that the balance swings indefinitely toward the platform and increasingly so. I would argue this has always been the case, and ODC has only accelerated the trend. When the value of contribution flows almost entirely to the platform while the contributor's portable reputation shrinks, the symbiosis starts looking a lot more like extraction. While this may read like a rant, it is not. The whole point is shifting the balance a little more toward the developers who are giving their time, energy, and expertise to make this a better platform. This is about symbiosis: balancing the ecosystem so that the people who build it up are built up in return. The goal is to make the entire platform stronger by honestly acknowledging where it falls short. With that I'll leave my idea. Contributions from Forge or otherwise, should be something that a contributor can showcase to those outside the OutSystems ecosystem. If a contributor only reaps benefits from their contributions inside the OutSystems ecosystem and stands nothing to gain outside of it, it is not a favor to the developer and the main benefactor is clearly OutSystems. In time, I do not think that is beneficial for OutSystems and the broader platform.

If this is possible, I'm not seeing it. In O11 you can download a forge component without having to install it. In ODC this seems impossible. Why? I want to see what's in a forge component before committing to installing it in my environment. I have done this for as long as the forge exists. Why would you take away this option?