OutSystems provides strong local debugging (breakpoints, step‑through execution) and logs, and in ODC it already supports distributed traces at a technical level. However, from a developer’s point of view, there is still a significant gap between raw observability data and actionable troubleshooting. I’m proposing a developer‑centric, end‑to‑end request trace experience that makes it easy to understand what happened for a single user action: from the UI event, through server logic, to database operations and external integrations, without manual correlation. Service Studio debugging works well within a module, but once a request crosses: UI → Server Actions Aggregates → Integrations Async flows / Timers developers must manually jump between: Debugger Logs Integration error screens External system logs This fragmentation slows down root‑cause analysis and increases support effort, especially for intermittent or environment‑specific issues. Logs show facts / data, but not context. Logs record events, but: Developers must manually infer which UI action triggered which server/integration call Correlating logs across layers requires custom correlation IDs or naming conventions Performance issues often require guesswork to identify the slow component Traces technically capture request lifecycles, but developers don’t yet have a single, intuitive “story view” of a request that ties everything together in a one‑click request trace view that: Starts from a user action (e.g., button click, screen load) Shows the full execution chain across: UI action Server actions Aggregates / queries Integration calls Async operations (where applicable) Presents timing, failures, and context in a single timeline This is not about adding more logs, but about connecting existing observability data into a developer‑friendly narrative.

Currently we have to use non -native methods to enable popup closing by clicking outside. It would be interesting to have it natively.

Hi everyone, I’ve noticed something with the "Duplicated Code" pattern in AI Mentor that has been causing a lot of false positives in real projects. Right now, the detection seems to focus mostly on the Action flow structure (basically the “shape” of the logic). The problem is that many Actions in OutSystems naturally share the same simple pattern, like: Start → SQL → Assign → End So even when two Actions have completely different SQL queries and return different Output Structures, AI Mentor still flags them as duplicated just because the flow looks the same. In practice, these aren’t duplicates at all. They just follow the same architectural pattern. Trying to merge them usually doesn’t make sense, can hurt readability, and sometimes even impacts performance. Suggestion It would help a lot if the duplication check also considered the SQL widget details and the Action contract, not only the flow. For example, avoid flagging when: the SQL statement text is clearly different the Output Structure is different the returned data shape is different Maybe duplication should only be reported when the flow and the SQL and the outputs are very similar. This would make the detection more semantic instead of purely structural. Benefits Reducing these obvious false positives would: • Reduces false positives • Less time wasted marking valid code as “Won’t Fix” or "False Positive" • Prevents unnecessary refactoring that may hurt performance • Increases developer trust and adoption of the tool I think this small change could make the Duplicated Code pattern much more accurate and much more valuable in day-to-day development. Thanks!

Being able to see line numbers when editing CSS/JS files larger than 50 lines is a must. Currently I'm fighting through a 7000 line JS without this feature, and it's really a pain. Thanks community for voting this up and thanks OS for implementing this today :)

Hello Everybody,I want to propose a new idea:The possibility of the lifetime applications can be divided by different streets Why is this important?When you have an infrastructure with many environments (9 in my case), it becomes difficult to make the management through the lifetime applications list The problem:I have 6 environments in my infrastructure and two DEV environments(Street 1: DEV, TST, PRD) + (Street 2:  DEV, TST, PRD)When developers publish the second DEV Environment (BA DEV) they get a warning like it’s a hotfix and that they should propagate to the previous environmentsBut I don't wanna propagated backwards because I'm developing in a new street of environments. The solution :Add the possibility to create Streets and shows only the environments in this street.

Just like "Is Auto Number" option Have an "Is Auto UniqueIdentifier" option to automatically generate GUID for entity primary key id.

Be able to restore the Screen State in Mobile apps while navigating through screens. By default, OutSystems already uses an hidden API (ScreenStateCache) that restores the screen state while navigating back to the previous screen, as stated in my article . The implementation of this idea would make this functionality available across the developers, making OutSystems mobile apps with an user experience much closer to the native ones.

As confirmed by OutSystems in this forum topic , data fetch actions are not optimized and instead passing all screen data in every request payload. Even if the parameters are not used anywhere in the data action. Please optimize this.

Hi,Service Studio could help our developers in maintainability/architecture tasks doing an analysis on all "Unused public objects". This option could be something like "Remove Unused Dependencies" but could check all objects that don't have usage in other modules.+ will allow developers keep applications smaller, delete unused features+ spare a lot of time, because this tasks is manually our days+ already have a manual task for that, so Outsystems will only automate, no extra work needed

When you name a variable the Outsystems platform automatically sets a data type based on that name. When you create a new variable, this behavior is mostly correct and helpful. Sometimes however, the platform is just plain wrong in guessing the data type. No sweat, you change the data type manually and the problem is solved, so you would think...However, when you now copy that variable and change the name of that copy, the platform again tries to guess the data type and, yes, again it guesses wrong. Even when you rename the original variable the same thing happens: wrong data type again. The result of this behavior is that you have to manually change the data type again, and again, and ... yes, every time you rename a variable! This becomes a frustrating exercise very fast!To prevent this issue I would like to propose that setting the data type of a variable automatically is NOT performed when either,- the data type was set manually by the developer- the variable was copiedPlease vote for implementing this if you agree.