An app where developers can create AI Agents using Mentor inside ODC, guided, structured, and production-ready. A lightweight app that helps developers: Define an Agent purpose Generate the System Prompt Suggest Actions Recommend Grounding strategy Propose Memory configuration All using AI guidance with Mentor.

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.

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.

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.

It is possible to consume a REST API using the PATCH method, but it isn't possible to expose a REST API with it. PATCH is meant for selectively updating data (instead of all at once, like PUT). I would like the Platform to support PATCH for an exposed REST API as well.However, PATCH is useless without being able to detect which fields (Attributes) have been sent by the calling party. Currently, if a consuming party doesn't send all the fields, the Platform will set them to the default value. This works for most cases, but not for a PATCH. Therefore, when supporting PATCH, there must be some way (via a runtime property) for the Platform to indicate which fields have been sent, and which were not.

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.