Upgrade the standard File Upload widget to a comprehensive "File Manager" component. Beyond just uploading, this widget should natively support: Removal: Easily delete a file before submission. Review: Integrated Preview and Download actions for subsequent users in a workflow. This eliminates the need for developers to build custom "Download/Preview" patterns every time they create an approval-based form, providing a seamless experience for both the uploader and the reviewer.

Many REST services implement sending files, documents etc. by having a body with multipart/form-data. There are many questions on the forum about this, e.g. here , here and here . Unfortunately, the OutSystems Platform lacks native support for this, leading to workarounds like this Forge Component or "manually" modifying the request data in the OnBeforeRequest, which leads to things ugly code like this:(Yeah, that's mine :).)So it would be a great addition to the Platform if it had native support for multipart/form-data for REST services, at the very least for consuming them. That would make our lives just a tad bit easier!

Add a way to filter the logs by excluding keywords. Use case : one of our process calls an external API using ArdoHTTP and every call results in a SLOWEXTENSION log, thus flooding the general log with pages of useless logs. This makes trying to find significant logs very difficult and time consuming. Being able to filter out by keywords, ie SLOWEXTENSION, would solve this issue.

While working in Service Studio using Dark Theme, selected elements such as Assigns, Decisions, Aggregates, Actions, Loops, and Connectors can be difficult to identify, especially when: Screen brightness is low. Working with large and complex logic flows. Presenting or sharing screens during meetings. Currently, the visual difference between selected and non-selected elements is quite subtle, making it challenging to quickly locate the active element and follow the execution flow. Suggestion: Introduce a High-Contrast Selection Border for selected elements. When a node or connector is selected, display a thicker, high-contrast border (for example, bright cyan, yellow, or orange) around the element. This would make the selected element immediately stand out from the surrounding workflow, improving visibility, reducing eye strain, and enhancing productivity when working in dark environments or on large server actions. This enhancement would significantly improve the overall usability and accessibility of Service Studio's Dark Theme experience.

There could be some magic feature that would make this time saver feature. :-)Then we could make a simple query to build the 'skeleton' of a query and then introduce the aditional rules that cannot be defined in a simple query.

On placing an element on the screen and filling, like a dropdown or a input that platform could provide a conventional name for the widget related to the variable name it is set. Instead of Dropdown1, it could be for example DropdownJobTitle if it is related to the JobTitle variable. Same applies to Buttons. This happens on the Input fields of the forms, when the form is auto generated with the Screen Aggregate.

Right now when a user navigates to a URL that is not associated with a page or the URL for a page that has been removed, you end up at an ugly 404 page located in /customHandlers/ As seen in this forum post you can edit the custom Handler's page directly, but my understanding this would change it for all apps, and doesn't seem possible in a Cloud environment. It would be nice if we at least had the option of configuring the 404 page, similar to the Invalid permissions or Internal error pages. Especially if one of the inputs of this page was the originally attempted URL, meaning we could redirect the users if they were attempting to go to an old screen that was removed, but the content is now elsewhere. Thanks!

IDEA: Creation of an environment for certified developers (with at least 6 months or 1 year of certification) where he/she could test the advanced skills to pass the professional certification, the management of environment, lifetime, to create plugins or give support to the ones created when had access to such environment, etcThis would solve the lack of practice of many developers who want to give an extra step in the career and don't have opportunity to test in the company where he/she is working and would spend months or years just with theoretical knowledge until have the opportunity to test what have learnt; and for the developers who created a component but no longer have access to the lifetime would be a good chance to update the components.

 Challenge: Currently, widgets in Service Studio don't have names by default. Developers typically only assign names when they need to manipulate widgets in business logic. However, widget names are essential for test automation because when a name is defined, the generated HTML element ID includes a static part (based on the widget name) alongside the dynamic part. This static portion can be used as a reliable selector in test scripts. Without named widgets, HTML element IDs are entirely dynamic, making test automation scripts fragile and prone to breaking whenever screen changes are made. This forces QA teams to constantly update test selectors. Proposed Solution: Auto-generate unique default names for widgets within each screen (e.g., Button1, Button2, Input1, Table1). This would: Provide stable HTML element IDs for test automation without requiring manual developer effort Make test scripts more robust and maintainable Reduce the time spent fixing broken tests after UI changes Improve overall application testability out-of-the-box Trade-offs: This would make the HTML slightly more verbose, but the impact would be minimal compared to the significant benefits for test automation and quality assurance workflows.

Currently, AI helps generate code, but one of the biggest challenges in enterprise OutSystems applications is understanding existing applications. I would like to suggest an AI-powered assistant capable of analyzing an existing module and explaining: • Screen and module responsibilities • End-to-end business flow • Server Actions and Client Actions relationships • Dependencies between modules • Entities and data flow • Integration points (REST, SOAP, Events) • BPT processes • Timers and Scheduled Jobs • Security model (Roles, Permissions) • Reusable components usage • Architecture recommendations • Technical debt detection • Suggestions for SOLID and architecture improvements This feature would be extremely valuable when: - Joining an existing project. - Maintaining legacy applications. - Performing code reviews. - Onboarding new developers. - Supporting technical leads and architects. Instead of simply generating code, AI could become an intelligent documentation and architecture assistant, helping teams understand large enterprise applications much faster. This would significantly reduce onboarding time and improve productivity for development teams.