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.

Extend the platform's JavaScript Node and Client Action invocation contract to include a fifth built-in parameter: $event, exposing the native browser Event object alongside the existing $parameters, $actions, $roles, and $public. The change would be additive and non-breaking - I assume. Use case : implement an OnKeyUp handler that runs logic only when Enter is pressed, without manually wiring addEventListener/removeEventListener — the platform already manages the event listener, it just needs to forward what it receives.

Hi If I'm using Data Fabric connector for O11, I get a Private Gateway out-of-the-box, creating a secure, encrypted tunnel between my ODC tenant and my O11 environment. If I'm doing REST API O11 ODC, I still have to design connectivity myself. OutSystems provides coexistence capabilities between: -OutSystems 11 (O11) -OutSystems Developer Cloud (ODC) These allow to: -Expose APIs/services from O11 to ODC Consume O11 logic from ODC apps (and vice versa) However: This is based on standard integration mechanisms (REST APIs, networking configuration, identity setup), not on an automatically provisioned “private gateway”. For this situations where the services are on O11 set the REST API property API Consumer to ODC and on ODC are set to REST API property API Producer to O11 it would be useful to have a Private Gateway out-of-the-box. Regards

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.

Hi, this is just an idea for a developer's perspective, it would be nice to have the ODC workflow builder in ODC Studio itself instead of going back and forth from ODC studio to ODC Portal when developing for the workflow.

Currently, when a developer enables a breakpoint in a shared environment (like Dev or Test), all active sessions hit that breakpoint. This disrupts other developers and interrupts their work. Introduce a "Debug My Session Only" toggle within Service Studio. When enabled, breakpoints would only trigger if the request originates from the developer’s own authenticated user session or specific IP address.

Currently, in OutSystems Service Center > Factory > Modules > [Module] > Operation tab, users with "Open" and "Debug" permissions can view essential settings like Audit Stack Display, Run Mode, Debug Mode, Deployment Zone, and Light Logging. However, the critical "Light Process Execution" checkbox—which enables lightweight BPT for improved throughput—is not visible or determinable. This checkbox is shown in full admin views (first attached image), but hidden for Open/Debug users (second attached image), preventing developers from confirming if Light BPT is enabled without elevated access. Requested Feature:Display the "Light Process Execution" setting (checked/unchecked status) in the Operation tab for any user who can access module details via Open/Debug permissions. This ensures consistency: if a user sees module operations, all relevant toggles should be readable. Business Impact: Developers troubleshooting performance can't verify Light BPT without admin help, slowing debugging in teams with role-based access. Promotes self-service in Service Center, aligning with OutSystems' low-code efficiency. No security risk, as it's read-only visibility matching existing fields like Debug Mode. Steps to Reproduce: Log in to Service Center with Open/Debug-only permissions. Navigate to Factory > Modules > [Any module with Light Process]. Go to Operation tab—note "Light Process Execution" is absent. Please prioritize this for better module visibility in O11

Since we have the 1-Click Publish with Message, it would be great if we can set by default in settings, where Mentor to generate the message for us based on the changes made from previously published version.

Currently, when a mobile or reactive app client disconnects mid-request (e.g. user backgrounds the app, loses network, or a timeout occurs), OutSystems logs the following errors in Service Center as 500-level errors: "The client is disconnected because the underlying request has been completed. There is no longer an HttpContext available." "Failed to send request due to unexpected error" These errors are thrown deep in the ASP.NET/IIS pipeline by the ErrorNotifierModule, below the OutSystems application layer. This means developers have no way to catch or suppress them using OutSystems logic — not through OnException handlers, not through error handling in Client/Screen/Data Actions, and not through any pattern available in Service Studio. Why this is a problem: These errors are not actionable by developers — there is no OutSystems-level fix that prevents them They pollute the error log in Service Center, making it harder to identify real application errors (we currently have an average of 60.000 daily errors like these) They generate false alerts in monitoring tools and APM integrations that consume OutSystems error logs They cause unnecessary noise in production environments, particularly for mobile apps used on unreliable network connections What we are asking for: OutSystems R&D to implement one or both of the following: Suppress specific known client-disconnect exception types (e.g. HttpException with error code 0x800703E3) in the ErrorNotifierModule before they are written to the error log, since these represent expected network-level events, not application bugs Provide a configurable filter mechanism in Service Center or Factory Configuration that allows platform administrators to define error message patterns that should be downgraded (e.g. to a warning) or excluded from the error log entirely Expected outcome: Developers and operations teams can maintain clean, actionable error logs that reflect real application problems — without being forced to implement infrastructure-level workarounds outside the OutSystems platform.

Create a system action in ODC where a message can be logged to the error log. LogMessage will log a message to the general log. O11 has the AsynchronousLogging extension that has a LogError action, but ODC does not. In ODC, an application can log to the error log by throwing an exception. However, there are occasions when the application needs to continue processing. In this scenario it would be useful to log a message to the error log and continue operation.