Currently, the OutSystems UI stylesheet applies a box-shadow effect through :focus when accessibility features are enabled. As a result, the focus indicator is shown both for keyboard navigation and mouse interaction. It would be preferable to use :focus-visible instead, so the focus indicator is only displayed when it is relevant, namely when users are navigating with the keyboard or using assistive technologies. This would provide a more appropriate default behaviour, improving the experience for mouse users while preserving a clear and accessible focus state for keyboard navigation.

Full widespread support for null values, in all layers: database, actions, ...Not fake zeros disguised as nulls, but real thing, the ones that we can compare to is null. The ones that mean "I don't know the value for this... I don't even know if its zero"

Implement an active Artificial Intelligence prompt directly integrated into Service Studio / ODC Studio, capable of analyzing OML files to detect issues, suggest improvements, and propose corrections , both automatically and through clear, detailed explanations of the proposed solutions . The idea is to allow developers to select a module or a set of elements (Actions, Aggregates, Entities, UI, integrations, etc.) and request an intelligent analysis that can: Identify logic, performance, security, and best-practice issues Suggest architectural and code readability improvements Clearly explain the root cause of each issue and the recommended solution Optionally apply automatic fixes or generate assisted refactoring suggestions An initial approach could involve exporting the OML for analysis by an external AI model (such as ChatGPT or Claude). However, the key differentiator would be having this capability natively embedded within the Studio , removing friction from the development workflow and improving application quality directly during development. Modern development tools already leverage AI for code review, refactoring, and optimization , delivering measurable gains in productivity and code quality. Bringing this capability deeply into the OutSystems platform would deliver significant value to developers , reinforcing OutSystems’ position as a leader in intelligent, AI-assisted low-code development.

I would like to be able to use HTML content in the email body in Reactive apps.Html content is needed to sent emails with a nice layout from Reactive apps.Expressions in Traditional Applications have the "Escape Content" attribute. When you set it to "No" a mail sent by a Traditional Application is delivered as a HTML Document. This is not possible in Reactive applications.The HTML Element can also not be used in an email in Reactive app.The only current solution would be, to create a Traditional Application just for sending the email and provide a public EmailSend-Method. But that is a lot of overhead just to send a mail.

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

 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.

Would be a (minor) quality of life feature if you could bind a label to an input if you simply drag and drop it from the tool box on the left straight on the Input widget. For example here, this widget is bound to a "Max records" local variable, to control how many records an aggregate returns. If I drag the label on to it, it could do several things: Add the label on top of the Input Set the Input Widget automatically on the Label properties, and give it a name like "InputName_Label" Set the text for the label on a 'best guess' case, depending on what the input is bound to (for example here, Max records) This could work for all other input type widgets: text area, switches, checkboxes, dropdowns, etc.

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.

 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.

 Problem In large modules, unused local variables, input parameters, output parameters, and assignments can accumulate over time. This makes the code harder to maintain and can confuse developers during debugging. How this suggestion can help A better unused element detector would improve code quality, reduce technical debt, and help teams clean modules before publishing. Implementation example Service Studio could show warnings such as: Local variable 'TempStatus' is never used. Input parameter 'RequestId' is not referenced. Output parameter 'SuccessMessage' is never assigned. It could also provide a quick action: Remove unused variable