The current Community platform suffers from performance limitations and provides a restricted level of user interactivity. To improve the overall user experience, I propose migrating the Community to a Reactive Web architecture within OutSystems. The growth and increased user engagement in the OutSystems Community can be attributed to a more intuitive, faster, and interactive experience that encourages users to actively participate, share knowledge, and return to the platform more frequently. Let’s move forward with this improvement to unlock a faster, more engaging, and truly collaborative community experience for all users. This is a developer’s observation based on system usage and user experience.

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.

As part of our ongoing effort to follow OutSystems best‑practice architecture, we have restructured our application landscape to clearly separate business logic from front‑end applications. While this approach improves modularity and maintainability, these applications still have interdependencies, which we group and manage as a logical Suite. When deploying to another environment using Lifetime, all module dependencies are automatically validated and republished as needed, and we are proactively notified of any breaking changes across dependent applications. This capability significantly reduces deployment risk and ensures consistency across the suite. It would be extremely valuable to have a comparable feature in Lifetime that allows us to publish a Deployment Plan within the same environment, while still performing full dependency validation. Ideally, this process would identify broken dependencies, prompt corrective action, and automatically republish all dependent applications as required. Implementing this capability would result in substantial time savings for developers. Today, deploying changes within the same environment often requires manually opening and publishing multiple modules in the correct order, with limited validation feedback and a high risk of human error. A unified, dependency‑aware deployment mechanism would both streamline this process and strengthen application stability. While we have implemented a workaround using Solutions in Service Center, it does not provide the same level of validation and dependency checks that Lifetime performs during cross‑environment deployments. Closing this gap would significantly improve deployment efficiency, reduce rework, and enhance overall application dependency management.

Service Studio already ships with a powerful but underdocumented headless execution mode. Through hands-on reverse engineering, we have confirmed and validated the following commands: -d (diff), -refresh, -u, -uu, -exportSettings, -importSettings, -cleanup, -removeChangeTracking, -runTests, -export, -import, and -silentrecover. These existing commands prove that Service Studio is architecturally capable of running fully headless, without opening a GUI. This proposal builds on that foundation to request ten new CLI commands that would unlock: AI-powered codebase analysis on .oml files without a running GUI CI/CD pipeline integration via GitHub Actions, Docker, and Linux environments Automated dependency management, publishing, and solution creation Programmatic introspection of modules, applications, elements, and SS_Keys These requests do not change the OutSystems platform concept or runtime. They expose what the IDE already does — through a command-line interface that can be scripted, automated, and run in containers. Proposed New Commands 1. ss list-apps — List Applications with Names and SS_Keys Problem: There is no headless way to enumerate the applications available on a server, along with their SS_Key (the GUID used by servicestudio:// deep links and LifeTime APIs). 2. ss list-modules — List Modules with Names and SS_Keys Problem: Modules are the atomic unit of development in OutSystems, but there is no headless way to enumerate them with their SS_Key GUIDs — the identifiers required for servicestudio:// protocol links and element navigation. 3. ss check-deps — Verify Module Dependencies Before Publish Problem: Before publishing a module, a developer needs to know if its dependencies are up to date, or if a producer module was published with breaking changes. The current workflow requires opening Service Studio, navigating to "Manage Dependencies," and manually inspecting each reference. There is no headless equivalent. 4. ss publish — Publish a Module Problem: There is no headless command to publish a module to a server. The current workflow requires opening Service Studio and clicking "1-Click Publish." This blocks full CI/CD automation. 5. ss republish — Republish a Module (Service Center Style) Problem: Service Center provides a "1-Click Publish" that recompiles and redeploys a module using its last published OML source, without requiring the source file on disk. This is critical for environment redeployments, disaster recovery, and CI/CD rollbacks — but it has no CLI equivalent. 6. ss list-elements — List All Elements of a Module by Name and SS_Key Problem: To use the servicestudio:// deep link protocol (e.g., to link directly to a specific action from a CI report or an AI analysis tool), you need the SS_Key of the element. Currently, the only way to get element keys is through direct database access or by reverse engineering internal API calls. 7. ss add-action — Add a Simple Action Using a Mermaid-Style Flow Definition Problem: Creating a simple server or client action in Service Studio requires opening the GUI, navigating to the correct module, and manually building the flow. For repetitive, pattern-based actions (logging, error handling, standard API calls), this is a barrier to AI-assisted code generation. 8. ss for Linux — Docker and GitHub Actions Support Problem: Service Studio is currently only available for macOS and Windows. This means CI/CD pipelines running on Linux (the default for GitHub Actions, GitLab CI, and most Docker containers) cannot use any Service Studio CLI commands. This is the single biggest blocker for full OutSystems DevOps automation. Request: Provide a headless Linux build of Service Studio — or a dedicated CLI package — that supports the full set of headless commands (existing + proposed) on: Ubuntu 22.04 / 24.04 (standard GitHub Actions runners) Alpine Linux (Docker optimization) Debian-based containers 9. ss delete-unused-refs — Delete Unused References from a Module Problem: Over time, modules accumulate references to producers that are no longer used — dead imports that slow down compilation, add maintenance overhead, and generate noise in -refresh / -u verification output. Service Studio can detect these via "Manage Dependencies," but there is no headless way to auto-clean them. 10. ss create-solution — Create Solutions Programmatically Problem: Solutions in OutSystems are the primary vehicle for managing and deploying groups of modules across environments via LifeTime. Creating and maintaining solutions is currently only possible through the Service Center UI. For teams managing complex multi-module deployments, the lack of a CLI solution creator is a significant DevOps gap. Why This Matters: The AI Analysis Use Case The combination of -listModules, -listElements, and the existing -d (diff) enables a use case that is currently impossible: AI-powered static analysis of OutSystems codebases without a running GUI. Current Gap: To analyze an OutSystems application with AI today, a developer must: Manually open each module in Service Studio Navigate through hundreds of screens, actions, and flows Copy/paste relevant information into an AI tool The AI agent can then generate a report like: "Action IsElegivelAntecipacaoDZero (key: 11ea244a-...) accesses the server on every screen load. Consider moving this to an Aggregate with proper caching. → [Open in Service Studio](servicestudio://-downloadAndOpen -eSpaceKey 6acebf97-... -elementKey 11ea244a-... -url bin.dev.myenvironment.com)" This is only possible if -listElements exposes SS_Keys in its output. Summary We are requesting 10 new headless CLI commands for Service Studio, with Linux support as the foundational requirement for CI/CD automation. The existing headless CLI (-d, -refresh, -u, -exportSettings, etc.) proves the architecture is ready. These new commands extend that foundation to cover the full development lifecycle — from introspection and dependency management, to publishing, solution creation, and AI-powered analysis. The OutSystems platform is already exceptionally powerful. These commands make that power accessible to modern DevOps and AI tooling workflows, without changing a single line of platform behavior.

Hi Outsystems teams, Since the OS charing static entity for 1 AO, to save some cost for clients, in many projects, we hardly use static-entity even though it should use Static-entity for many purposes. We need to use alternative ways to implement the static concept, like using structure, hardcode... This led the development become more complex in design, implement, and more hard-code used, but we can't spend 1 AO for just 5 records stored in static-entity like status, type, etc... Actually many projects opened just to Delete all static entity from the code to save cost. From begining we've learnt how to use Static entity, and in real project we need to learn how to not use Static entity to save AO, this make static entity very dead. Can Outsystems consider to lower the price of AO somehow like count it 1 AO = 3 or 4 static entity, or consider make it free if there are < 10 record store in static entity, this would be a great thing for Outsystems developers and clients. Thanks :)

 Problem: When working with complex Advanced Queries in Service Studio, it is difficult and time-consuming to manually re-enter test values every time, especially for queries with many parameters. There is currently no native way to save these test sets. Proposed Solution: I suggest implementing a "Stored Test Values" feature for Advanced Queries to improve developer productivity: Versioned Test Values: Allow developers to save specific sets of input values as named "Test Versions" directly within the query editor. Auto-populate: Provide a dropdown or selector in the test input window to quickly select and auto-populate these saved values. Multiple Sets: Support saving multiple test scenarios (e.g., "Empty Inputs," "Edge Case - Nulls," "Standard Load") for the same query to streamline repetitive testing. This feature would significantly reduce setup time and ensure more consistent, repeatable testing during the development phase.

 Problem: Even after years of development, maintaining consistent code quality across large teams is a persistent challenge. Despite the existence of best-practice documentation, junior and even senior developers frequently bypass critical standards—such as proper documentation, naming conventions, Max. Records settings, or inefficient operations like lists within loops. Currently, code review is a manual, reactive process that happens too late in the development lifecycle. Proposed Solution: I propose a new "Governance Gatekeeper" feature for Service Studio, powered by existing AI Mentor capabilities, that moves code quality from "suggestion" to "enforcement." Policy-Driven Publishing: Allow Admins to configure a set of "Strict Quality Rules" for specific modules. If the modified code fails to meet these pre-defined standards (e.g., missing descriptions, non-compliant naming, or performance anti-patterns), the 1-Click Publish button is disabled, preventing the deployment of substandard code. Granular Control: Provide the ability to toggle these restrictions on or off per module or application. This allows organizations to apply strict "Production-Level" enforcement on core systems while maintaining flexibility in "Sandbox," "Learning," or "PoC" modules. AI-Powered Feedback: Integrate the AI Mentor to not only block the publish action but to provide a clear, real-time "Action Plan" telling the developer exactly what needs to be fixed to unlock the publish button. Impact: By integrating automated enforcement into the development loop, we can: Guarantee Technical Debt Reduction: Prevent bad patterns from entering the codebase at the source. Scale Mentorship: Use the platform to train developers in real-time, effectively automating the role of a lead developer in enforcing standards. Elevate Enterprise Reliability: Ensure that all production-bound code meets a uniform level of quality, documentation, and performance before it ever hits the server. Thanks

Be able to create a unit test for a Server / Service / Client (?) / Screen (?) action that shall be executed without developer intervention, for regression purposes.

To add a link or a way to quickly open the Event Handler Action from Properties / Events of UI Widget. This can be extended to On After Fetch of Fetch Data From Server or UI Aggregrate. This will improve the developer experience to quickly open the Client/ Screen Action that assigned as Event Handler or After Fetch Event rather than scroll up and down Elements Tree For Button and link, we can quickly double click the Element in the canvas to quickly access the OnClick Event Handler already, however, this should be good if there's a similar way for other Widget like Dropdown, Switch, Custom WebBlock with Events, Data Fetch Aggregate...

Currently, when a mobile or reactive app client disconnects mid-request (e.g. user backgrounds the app, loses network, or a timeout occurs), OutSystems logs the following errors in Service Center as 500-level errors: "The client is disconnected because the underlying request has been completed. There is no longer an HttpContext available." "Failed to send request due to unexpected error" These errors are thrown deep in the ASP.NET/IIS pipeline by the ErrorNotifierModule, below the OutSystems application layer. This means developers have no way to catch or suppress them using OutSystems logic — not through OnException handlers, not through error handling in Client/Screen/Data Actions, and not through any pattern available in Service Studio. Why this is a problem: These errors are not actionable by developers — there is no OutSystems-level fix that prevents them They pollute the error log in Service Center, making it harder to identify real application errors (we currently have an average of 60.000 daily errors like these) They generate false alerts in monitoring tools and APM integrations that consume OutSystems error logs They cause unnecessary noise in production environments, particularly for mobile apps used on unreliable network connections What we are asking for: OutSystems R&D to implement one or both of the following: Suppress specific known client-disconnect exception types (e.g. HttpException with error code 0x800703E3) in the ErrorNotifierModule before they are written to the error log, since these represent expected network-level events, not application bugs Provide a configurable filter mechanism in Service Center or Factory Configuration that allows platform administrators to define error message patterns that should be downgraded (e.g. to a warning) or excluded from the error log entirely Expected outcome: Developers and operations teams can maintain clean, actionable error logs that reflect real application problems — without being forced to implement infrastructure-level workarounds outside the OutSystems platform.