It would be great if we could for instance look for a search term only within queries, or only within assigns or parameters.

When exposing a REST API, OutSystems generates a swagger.json documentation for the endpoint. Used data structures are documented in the "definitions" section where their required attributes are listed by their name in the array called "required". Because the swagger file is mostly relevant for systems other than OutSystems, the internal name of the OutSystems structure is not of interest. Instead the required attributes should be listed by their JSON name like in the "properties" section:

Hi guys,I developed a mobile application in which deeplinking is not working properly in iOS since universal links concept is not yet implemented in OutSystems so I want that it should be introduced in OutSystems.It will be a blessing to deeplinking apps in OutSystems for iOS platform.

A native service studio plugin for Figma that doesn't just "import" but "links" components. Changing a padding value or a colour token in Figma should trigger a " suggested update" in Service Studio, allowing for" live code sync "between the design tool and the low- code IDE.

Currently all comments have the same color. In Dark Theme they appear black and in Light Theme they appear gray. This makes it difficult to distinguish important notes or identify who added them. The proposed idea is to allow users to define the color of their own comments so that in action flows it becomes easier to see who contributed. If full customization is not feasible an alternative would be to provide three predefined colors such as normal yellow and red to indicate severity or importance. This would help draw attention to critical comments and prevent them from being overlooked.

Add a Ranking column and sort to this list. This would be helpful to get an overview of the team ranking and check how active they are in the OutSystems community.

In O11 , when you copy logic, screens, or any other elements from one ( source ) module and paste them into another ( destination ) module, any external references used by the copied elements of the source module are automatically added to the destination module. This is quite helpful sometimes, especially when you are trying to copy screens/logic from one application to another (I had to do this a bunch of times in the past, for various reasons). However, in ODC , this is not the case. Once some elements (referencing some dependencies) are copied from one module to another, none of the references are automatically added (unlike in O11 ). This results in hundreds of errors sometimes, which could be reduced to just a few if automatic dependency referencing worked like in O11 . It would be great if this automatic dependency referencing is added to ODC as well, unless there's a valid reason for excluding this feature in ODC . Thanks in advance, looking forward to hearing about others' experiences and feedback :)

Native support for websocket (socket.io) to enable companies to build real-time data applications https://socket.io/ Note : We could setup node.js and socket.io on our own then integrate this with outsystems apps with but not everyone is going to know how to do that!

Sometimes it is necessary to use the executed sql and it would be very useful if you had some configuration to display the value of the variables.

When we add non-mandatory attributes to structures (for example input/output structure of a Service Action), there will be no impact on the consumer modules ONLY if the added attribute is a basic type. You can read this in the documentation Handle Changes in Exposed Functionality , 'The following changes made in the producer do not have impact on the consumer modules: ' Add an optional Attribute (basic data types only) Structure In my perspective, there should also be no impact on consumers when adding non-mandatory composite/complex attributes like adding a record, or a list, or list record... Here is a scenario we are facing right now. We use Service Actions instead of internal REST API's to promote a loosely coupled architecture. There is benefit in using Service Actions as the platform handles the security and findability of Service Actions, whereas with REST API's, you have to do it yourself. All our Service Actions communicate with input/output Structures. When we want to add a non-mandatory structure to the output structure of the service action, then the consumers are impacted. Now both applications have to be deployed together, which complicates loosely coupled deployment strategies. Here is an screenshot to describe the issue.