Looking at the authorizations offered while creating the connection to MCP (Model Context Protocol), all the options related to (OAuth) ask for a client secret as a mandatory field. While searching on MCP Documentation, the client side must implement a PKCE (Proof Key of Code Exchange) flow, with this flow its not mandatory to have a client secret to get Authorization to interact with the MCP Server. Making a lot of MCP Servers impossible to connect to OutSystems. Where is the link for the documentation where they explain why PKCE flow should be mandatory: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#authorization-code-protection My suggestion here is to make client secret not mandatory.

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.

 Problem Debugging layout issues in Reactive Web apps can be time-consuming. Developers often need to inspect CSS, containers, flex behavior, spacing, width, and alignment directly in the browser, but Service Studio does not provide a clear visual way to understand why a layout is breaking. How this suggestion can help A built-in Layout Inspector would help developers quickly identify spacing, alignment, overflow, flex/grid behavior, and responsive issues without switching constantly between Service Studio and browser DevTools. Implementation example Add a right-click option on widgets: Inspect Layout It could show: Widget: Container_Main Display: Flex Direction: Row Gap: 16px Width: 100% Padding: 24px Overflow: Hidden Parent Container: Section_Content It could also highlight margins, padding, and parent-child relationships visually inside Service Studio.

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.