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.

In some cases the feedback message widget is displayed to long/short. It possible to change that but then you'll need to clone the RW eSpace and make the change youself. It would be nice if there was a input paramter where the display time could be set. On this way it's more useble in different situations.

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!

First off, the "Create Action Wrappers" feature is really useful. When you right-click an Entity and generate the Create and CreateOrUpdate server actions, the platform already checks for Mandatory attributes. If a developer misses assigning a value to a mandatory field, an exception is thrown at the application level. That's a nice touch and saves a lot of headaches. One thing I noticed though is that for Text attributes, there is no validation on the defined Length. So if a developer passes a string that is longer than the max length set on the attribute, the value still goes through to the database and you get the classic "String or binary data would be truncated" error. That's a database level error, not an application level one, and it gives the developer zero context on which attribute caused the problem. Since the platform already knows the Length property of each Text attribute (in the Entity definition), it would be great if the generated wrapper could also validate against it. Same pattern as the Mandatory check, just extending it to include a Length check for Text attributes and throw a meaningful exception before it hits the database. This could help by: Making the generated wrappers more complete and consistent Giving developers clearer error messages during development and runtime Reducing unnecessary database round trips for data that was never going to be accepted anyway Really appreciate how the platform already handles the Mandatory side of things. This would just be a nice extension of that same thinking. Would be great to have this for both O11 and ODC. Thanks for considering!

It would be really helpful to have an "OutSystems Agent" that has knowledge about our codebases and can answer questions, generate insights, suggest actions, etc etc. It could also be connected to app metrics so we would be do some queries like: Why is X app slow today? What changed in the last deployment? Show me all missing role checks in app X Generate sample test cases for screen / action Y and so much more

To put it simply and directly: It would be great to be able to provide Mentor with a screenshot of a screen built in Figma. Who knows, maybe the Mentor can help create amazing projects with that.

If anyone is working on OutSystems and need any help with respect to platform Maintenace and support, I would be happy to help as per my knowledge. below one is one incident which we faced recently during the deployment. Issue - During deployment from dev to test it fails with error "Error executing query. ORA-01013: user requested cancel of current operation." Solution - These types of issues occur mostly when a query execution fails at database end due to time out. So in our case we opened the LifeTime configuration tool and increase the Default Query Timeout from 30 seconds to 300 seconds and then issues got resolved. Please share your ideas and suggestions also on OutSystems low code platform issues. Regards, Arun

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.

It is impossible to break/continue if you have more then one nested foreach cycle.Adding an action like a terminator to a cycle could lead to the previous one, for example.

I very much like the feature of automatically connecting to an environment, but more often than I would like to admit I find myself doing changes in an environment where I do not intend to. This is partly because the environment that is opened doesn't stand out that much.When opening (for example) a TST environment, the next time you open service studio, the TST environment will be opened (instead of the DEV environment, which was opened earlier).I see two options that might prevent this.1. Enable configuration per environment (in 'Manage environments' to enable/disable automatically connecting to that environment). You would probably want this for all non-dev environments anyway.2. Set a fixed environment to automatically connect to, instead of the last environment. I think it's true for a lot of developers that 95% of their work done is in one environment.