Using OutSystems Semantic Search for community pages such as Forums, Ideas, and Forge brings a step change in how community members discover knowledge and reusable assets across the ecosystem. Traditional keyword search relies on exact matches, which often leads to incomplete or irrelevant results, especially in large content bases like community discussions, ideas and Forge components. Semantic Search, by contrast, understands intent and context, allowing users to find relevant answers even when terminology differs from how content was originally written. For the OutSystems community, this has a few clear benefits. First, it significantly improves discoverability. Community members can find the right forum threads, idea submissions, or Forge components without needing to know the exact naming or tags used by the author. This reduces friction and increases successful self-service. Second, it increases reuse and reduces duplication. Better search results mean developers are more likely to find existing Forge components instead of rebuilding similar functionality, and more likely to engage with existing Ideas rather than creating duplicates. Third, it improves community engagement quality. When users quickly find relevant discussions or solutions, they are more likely to contribute back, vote on Ideas, or refine existing answers instead of starting new fragmented threads. Finally, it future-proofs the community knowledge base. As content volume grows, semantic understanding scales far better than keyword-based approaches, ensuring that search quality does not degrade over time. In short, Semantic Search turns the community from a static repository into an intelligent discovery layer, making knowledge, ideas, and reusable components easier to access, reuse, and extend.

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 :)

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

A centralized Developer Cheat Sheet for OutSystems Developer Cloud (ODC) would greatly help both new and experienced developers quickly understand and adopt the platform. Similar to the existing O11 cheat sheet, this should provide a concise overview of key ODC concepts, architecture, development flow, best practices, and differences from O11. It would serve as a quick reference guide to help developers ramp up faster and become productive in ODC projects with minimal learning curve. This resource would be especially useful for: New developers getting started with ODC Experienced O11 developers transitioning to ODC Teams looking for a quick refresher on core concepts Providing such a cheat sheet would improve onboarding efficiency, reduce confusion, and accelerate project delivery within the ODC ecosystem.

Since we have the 1-Click Publish with Message, it would be great if we can set by default in settings, where Mentor to generate the message for us based on the changes made from previously published version.

 Use-case: I have an app with many screens and tons of CSS classes defined in the style sheet; I decide I no longer need one or more screens, so I delete it/them; now, I have a bunch of CSS classes defined in the style sheet that are no longer used anywhere in the app. Problem: I don't want unused CCS classes in the style sheet, so now I'm forced to search for each class in the app to check if it's used or not before safely deleting its definition. Solution: there should be an easy way to "Removed All Unused CSS Definitions", just like there's a "Remove unused elements" (see image), and/or a visual cue on the Style Sheet, next to each unused CSS definition, to make it easy for thee developer to see that that particular definition is not being used (that way the developer can manually delete only the ones they're sure they'll never use again).

It would be highly beneficial if the Espace_Versions table included an additional column/attribute to store the publish/deployment comment that is currently supported through the recently added deployment comment option. Additionally, exposing the same information through the LifeTime APIs would greatly help customers build custom audit, monitoring, and deployment tracking solutions. This enhancement would provide better traceability of deployments, improve release governance, and help teams understand the intent/context behind each deployment without depending solely on external communication channels or manual documentation. Potential Use Cases: Custom deployment audit dashboards Release traceability and governance Tracking hotfix/business deployment reasons Displaying deployment comments in internal monitoring consoles Easier PROD publishes analysis and reporting Kind Regards, Sandeep

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.

Currently, in OutSystems Service Center > Factory > Modules > [Module] > Operation tab, users with "Open" and "Debug" permissions can view essential settings like Audit Stack Display, Run Mode, Debug Mode, Deployment Zone, and Light Logging. However, the critical "Light Process Execution" checkbox—which enables lightweight BPT for improved throughput—is not visible or determinable. This checkbox is shown in full admin views (first attached image), but hidden for Open/Debug users (second attached image), preventing developers from confirming if Light BPT is enabled without elevated access. Requested Feature:Display the "Light Process Execution" setting (checked/unchecked status) in the Operation tab for any user who can access module details via Open/Debug permissions. This ensures consistency: if a user sees module operations, all relevant toggles should be readable. Business Impact: Developers troubleshooting performance can't verify Light BPT without admin help, slowing debugging in teams with role-based access. Promotes self-service in Service Center, aligning with OutSystems' low-code efficiency. No security risk, as it's read-only visibility matching existing fields like Debug Mode. Steps to Reproduce: Log in to Service Center with Open/Debug-only permissions. Navigate to Factory > Modules > [Any module with Light Process]. Go to Operation tab—note "Light Process Execution" is absent. Please prioritize this for better module visibility in O11

The new 1-Click Publish With Message is a good idea, but to be useful, it needs improvements. 1. It should have the ability to hide the normal 1-Click Publish to force messages, or some other way to enforce this 2. The last message should automatically populate a new publish, or maybe a dropdown with the last 5 or so messages.