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.

Working with multiple environments simultaneously is a standard practice, but Service Studio makes it hard to distinguish between them at a glance. Currently, a developer must check the status bar to know if they are in Dev, QA, or Prod. Introduce an "Environment Theme" feature where we can assign a specific color to each infrastructure. If I'm in Production, the Service Studio UI (or at least the tab bar) should have a distinct color (e.g., Red). Add the environment name as a prefix to the tab title (e.g., "[PROD] MyModule"). This would prevent accidental changes in the wrong environment and significantly improve the UX for developers managing complex lifecycles.

Currently, when using the Advanced SQL tool in OutSystems, developers are required to define an Output Structure even for SQL statements that do not return any data — such as INSERT, UPDATE, or DELETE queries. This mandatory output requirement introduces unnecessary steps in the development process. It creates confusion for beginners and adds extra overhead to simple operations that are not supposed to return results. Proposed Improvement: Introduce two different types of SQL tools to improve clarity and usability: ExecuteSQL_Select: for queries that return data (e.g., SELECT). ExecuteSQL_NonQuery: for queries that do not return data (e.g., INSERT, UPDATE, DELETE). ExecuteSQL_Scalar: for single-value queries (e.g., COUNT, MIN, MAX). These naming conventions are inspired by C# and other modern frameworks and would help improve developer efficiency and code readability. This change would eliminate the unnecessary requirement of defining output structures for non-query operations and streamline the development workflow.

This is a project aimed for Portugal, in a first phase, but which can be extended to other countries.It is just an idea and I count on the support of this forum to make it grow and solve the challenges! VisionEnable and manage the delivery of food and basic goods, in the form of a basket, to people who are more prone to be infected with coronavirus, already has coronavirus or is in quarantine. PersonasHypermarketsVolunteer to indicate beneficiaries and transport basket delivery Use casesRegistration of Hypermarkets- Responsible for creating the basketsRegistration of Volunteers- Responsible for collection and delivery to the beneficiaries respective addressesRegistration of beneficiaries- Registration will be done by the volunteer who indicates a family that meets the conditions to be a beneficiary Challenges- How to check if the family should be considered to benefit?- Definition of the basket. Should we have multiple types with different prices?- Online payments (only).- How to deliver safely? User Stories (draft)US1 - Registration of Volunteers- With facebook or google and with indication of the area of residence to define a range of action- Indication of the hours available to make deliveriesUS2 - Registration of Hypermarkets- As OutSystems has a close relationship with Continente hypermarkets, it would be easier to articulate with them in a first phaseUS3 - Registration of Beneficiaries- This registration must be done by the Volunteers through their account.- Indication of name, address, number of people in the householdUS4 - Task assignment to the Volunteer- At the end of each day, generate a route for the volunteer, which should be done the next day.US5 - Task completion- The beneficiary must indicate that he received the basket.I hope that this helps to understand the idea and that it can grow with the support of everyone.Thanks!

If you try to use the Mod() (modulus operation, for taking the remainder) function in a Filter of an Aggregate, Service Studio gives an error:"'Mod' function cannot be executed in the database, so it can't receive any attributes from the aggregate as parameter."This is nonsense however, as Microsoft SQL Server has the corresponding "%" operator, and Oracle has a MOD() function, so both supported databases know how to perform a modulus operation just fine. Therefore, Mod() should be allowed in an aggregate.

Most of the times server actions, client actions can have multiple branches. While debugging each node is currently available it would save a lot of time if we could just hit continue and the app automatically highlights the full path the execution has traversed. The Idea is to have like a highlighted flow in the server actions, client actions, data actions etc. where developers can see exactly which flow the execution is going wrong in and make fixes accordingly. This would help debug faster, saving the time to actually understand what each node is doing and also understanding the logic on a broader level.

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.

Add native Passkey authentication support to OutSystems, enabling secure, passwordless login using platform-level passkeys (FIDO2/WebAuthn). Passkeys are becoming an industry standard (and for good reason) as they have multiple advantages over traditional authentication methods. From Fido Alliance: This could technically be implemented via a Forge component, but given the complexity and security criticality it would be much better if the platform handled it.

Right now when you want en entire Row of a table clickable (or another event), you need to put the OnClick event on every Row Cell and point to the same action every single time which is quite repetitive and prone to mistakes. If you add a new Row Cell because extra data needs to be shown, you need to put the OnClick action again for this specific Row Cell even though it point to the same end point as the other ones. It would be nice if we could put the event handler on the entire Row instead of on the Row cell. Like this, newly added Row Cells will automatically point to the same OnClick action and you won't forget it. The option to put different handlers on the different Row Cells should still stay. This would just be an extra way to make an Action for a whole Row at once.

To monitor errors in Service Center, having the kind of exceptions that have been raised could be very helpful. The exceptions are already on the error log but not their Type, for example, "Database Exception", "Security Exception" and for User Exceptions, it would be very helpful. Should have filters / categorized.