Hi, I've run into this a few times. I would like to have the ability to do a simple query with an IN clause, without having to rely on advanced queries. It should accept a list of Identifier. Today we do ( from an aggregate perspective): SELECT * FROM {TASKS} WHERE id = 1 or id = 2 or id = 3 But it would be really awesome if we could do SELECT * FROM {Tasks} WHERE id in (1,2,3) This allows us to do some pretty cool stuff with Lists setc ( eg you can now shim some of the more advanced sql functionality without writing advanced queries). An example would be: myList = SELECT id from People WHERE OrganisationId = 2 SELECT * FROM {Tasks} WHERE personId = myList Which would be 2 actions, and somewhat faster/cleaner than the current way Writing an advanced query ( frowned up by my companies' best practices guide - and I've also found advanced queries tend to be annoying to manage ) Looping through myList and putting the outputs into another list, which is then passed around (this also has a few nasties - lots of DB hits (albeit small ones), and refreshing this with paging is a pain

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.

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.

The new RFC has just been released. In the link below, you can find the specification for the new QUERY HTTP method: https://datatracker.ietf.org/doc/html/rfc10008 The idea is to implement it in Service Studio, so we can explore and experiment with this new HTTP method.

When building RAG pipelines in ODC against structured documents, the four native chunking methods treat all input as plain text. This works well for simple text stored in entity attributes but creates problems for documents that have structure: fenced code blocks, Markdown tables, and nested headings. A Markdown-aware chunking option would let developers preserve that structure during ingestion without needing a custom External Logic workaround. Three behaviours would cover most cases: heading path tracking so chunks carry their section context, code block atomicity so fenced blocks are never split across chunks, and table preservation so tables stay whole. The upstream Forge ecosystem already produces Markdown output via components like OmniDoc2MD . A native Markdown chunking method would complete that pipeline naturally. This is not a replacement for the existing methods. It is an additional option for teams whose documents have structure worth preserving.

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

Descriptions for Actions and other application elements must currently be written manually. As a result, they are frequently missing, incomplete or no longer aligned with the actual implementation. When developers join a project or work with unfamiliar or legacy applications, they often need to inspect the complete flow, inputs, outputs, queries, dependencies and exception handling just to understand what an Action is responsible for. Idea Add a “Generate with AI” option next to the Description property of an application element. For an Action, the platform could analyse: Its inputs and outputs The logic flow and decision branches Entities and aggregates it accesses Other Actions and integrations it invokes Exceptions and error-handling behaviour Relevant side effects, such as sending emails or updating data It would then generate a concise, editable description explaining what the Action does. For example: Starts the password-reset process for the supplied email address. If a matching user exists, it generates the reset information and sends a password-reset email. To avoid exposing whether an account exists, the Action returns success even when no matching user is found. The generated content should always be presented as a draft that the developer can review, edit and approve, rather than being saved automatically. Possible evolution The same capability could later be available for: Screens and Blocks Timers Entities and Structures REST and SOAP methods Processes or Events Entire modules or applications It could also identify when the implementation has changed significantly and suggest that the existing description may need to be regenerated. Benefits Improves application maintainability Reduces the effort required to document existing applications Helps new team members understand unfamiliar logic Makes code reviews and handovers easier Produces better context for future AI coding agents Encourages documentation to remain close to the implementation Important refinement The generated description should capture not only what the flow mechanically does, but also, whenever it can be inferred: its responsibility; its business outcome; important security or privacy behaviour; externally visible side effects; reasons behind non-obvious implementation choices. I attached a screenshot to provide an example. A weak generated description would be: Gets the user by email, resets the password and sends an email. A useful description would explain: - the deliberate fake-success path, because preventing user enumeration is the most relevant part of the implementation. I also prototype a possible UI for this using AI.

 The Problem: Currently, when a module is deleted, moved, or a developer's access permissions are removed, that module still appears in the "Recent Modules" left panel in Service Studio. When you inadvertently click on it, the platform tries to open it and throws an annoying error stating that you are not allowed to access the module (or that it doesn't exist). This litters the recent items list with "dead links" and creates friction in the daily workflow. Proposed Solution: Service Studio should automatically refresh or validate the "Recent Modules" list. If a module is removed from the environment or if the user no longer has permissions to access it, it should immediately disappear from the recent modules panel. Alternatively, clicking it could trigger a silent validation that removes the shortcut if the module is no longer accessible, instead of opening a dead end and throwing an error popup. Benefits: Cleaner UI: Keeps the Service Studio workspace organized and relevant. Better UX: Prevents frustrating and useless error messages. Efficiency: Saves developers time by ensuring every click in the "Recent" panel actually leads to a valid module.

In OutSystems Platform publishing is like comitting your changes to Version Management. It would be extremely helpful to be able to add comments on the 1 Click Publish process. This would be even more flexible if one could drill down these comments by changed object (webscreen, webblock, action, webreference action, etc)

As we are now having folders everywhere, please do the same for service studio main screen. This way applications can be grouped by context.