When creating a custom API log entity, it would be helpful to save a reference to the Service Center integration logs using the request key. We can use the Request_GetKey action to add the key to our custom entity. This key is visible on the Integration Details page or can be used to join the Log_Integration entity. Additionally, I propose the following improvements: 1. Add a “Request Key” column to the table on the Monitoring > Integrations screen in Service Center. 2. Include a filter field to search by “Request Key” directly in this screen. These changes would make it easier to find specific logs and enhance debugging and monitoring

Most of the screenshots provided on the forge components are hard to ready because they are too small. It would be great if we could click and see a larger version of the screenshot.

Currently, the built-in "List Clear" (both client and server) action only allows a single list input. When we need to clear multiple lists in the same logic flow, we have to call the action repeatedly for each list, which results in repetitive code and reduced readability. It would be a great enhancement if the "List Clear" action could accept multiple list inputs (like a list of lists or as variadic parameters) and clear them all in one go. This would reduce unnecessary duplicated calls and streamline logic implementation, especially in complex flows. This enhancement would improve developer productivity, reduce redundancy, enhance code readability, save time in complex flows, and make applications more maintainable.

Create a built-in function to Retrieve Environment Name from Environment Configuration in Service Center

Adding description automatically to a client action, server action, service action or data action after user finish its logic in it and publish it. So, developers can see it and modify accordingly if it doesn't match the actual description they want. It will save time in writing description for each and every action and it will be easy maintainable also. It will make other developers easy to understand the action logic.

Right now, creating splash screens for a mobile app in OutSystems is a convoluted process. Although we have clear(ish) documentation on how to do it, this still requires developers to adjust their resources to 26! different formats (and this number can grow in the future). Developers either need to do this manually or find a tool that does this for us, which is time consuming and error prone either way. I think OutSystems, in the "low code way" should take care of this by, for example, integrating with like capacitor-assets . This tool belongs to Ionic, which in turn is a part of OutSystems, so the integration should be seamless. Developers would only upload one version of the asset, and the platform would take care of the rest. If this is not a priority, I would at least update the OutSystems docs to recommend this tool and show the community how to use it. Cheers, Tiago

When I have both opened, I find myself trying to guess wich icon is that I want to click in.I can change it by myself, but maybe someone @ OutSystems could make some cool incons for them ;)

Idea Summary: Enhance the resilience of the OutSystems UI Date Picker widget initialization, specifically when testing mobile views using Chrome DevTools' device simulation. Currently, the widget does not always reinitialize properly after a hard refresh in this environment, potentially leading to confusion during development and QA. Issue Description: When simulating a mobile device in Chrome DevTools and performing a hard refresh, the Date Picker widget occasionally fails to initialize correctly. This behavior appears to be due to: JavaScript/UI libraries not consistently re-triggering widget initialization in simulated environments. The use of dynamic selectors (e.g., .active, input.form-control.OSFillParent.input.active ) in the widget’s initialization logic, which may not be immediately available after a refresh. Key Observations: On actual mobile devices (e.g., Safari on iOS), the widget functions reliably, even after refreshes. In Chrome DevTools mobile simulation, the widget behaves correctly on initial load or when toggling to mobile view but fails after a hard refresh. Impact: Creates confusion during testing and QA phases. May mislead developers into thinking the widget is broken. Increases friction when debugging using browser tools. Suggested Improvements: Make initialization more robust in simulated environments. Avoid dependency on dynamic class-based selectors that may not exist immediately on load. Implement fallback logic or explicit reinitialization to handle DevTools mobile simulation scenarios. Thanks, Senthil

It would be very nice to have a check box when deploying from environment to environment which would allow you to remove unused elements in all applications. Similar to how the feature works within Service Studio .I find it very helpful having everything at hand when developing  but once deployed to test or production environments there is no need for the extra baggage.

Removing unused references is a great piece of functionality.It is a little blatant in its execution though. It would be nice to be able to view the unused references and then select/unselect the ones you do not want removed yet.As an alternative, in the Manage Dependencies window, show which selected references are not currently used by way of some indicator.The second option might be slighlty easier to implement and also would exist in precisely the place where teh developer is busy making choices about these things.The existing Remove Unused References would then remain as a reference cleanup tool rather than a reference management tool.