Enable to Test an Action giving new input parameters.

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.

Full widespread support for null values, in all layers: database, actions, ...Not fake zeros disguised as nulls, but real thing, the ones that we can compare to is null. The ones that mean "I don't know the value for this... I don't even know if its zero"

In OutSystems 11, developers could leverage GetRequestKey to correlate custom application logs with platform logs. In ODC, there is currently no supported way to access the runtime request identifier (Request ID / Trace ID) that appears in ODC platform logs. Many customers implement custom auditing and logging solutions to capture business events, troubleshooting information, integration payloads, and operational diagnostics that are not covered by platform logging. Without access to the ODC request correlation identifier, it is difficult to connect custom logs with platform-generated logs during incident investigation and support activities. Problem When analysing issues, developers and support teams often need to combine: ODC platform logs Custom audit logs Custom application diagnostics Integration and business process traces Currently, there is no straightforward way to correlate these data sources using a common request identifier. Proposed Solution Expose the current runtime Request ID / Trace ID through a built-in ODC API or System action, similar to the GetRequestKey capability available in OutSystems 11. Example: GetCurrentRequestId() or GetCurrentTraceId() The returned value should match the identifier used internally by ODC platform logs so that developers can store it in: Custom audit tables Application logs Observability platforms External monitoring solutions Support diagnostic records Use Cases Audit Log Correlation Store the ODC Request ID in a custom audit table, allowing support teams to quickly find the corresponding platform log entries. Enhanced Application Logging Capture additional business and technical details not supported by platform logs while maintaining full traceability. Customer Support When customers provide an audit record or transaction ID, support teams can immediately correlate the request with ODC logs. Integration Troubleshooting Follow a request across custom logging, integrations, business logic, and platform logs using a single correlation identifier. External Observability Platforms Forward logs to SIEM and observability tools while preserving correlation with ODC runtime logs. Business Value Faster incident investigation Reduced support effort Better observability and diagnostics Easier adoption of enterprise logging practices Feature parity with a commonly used OutSystems 11 capability Improved integration with external monitoring and audit solutions Additional Context Even when customers do not retain ODC logs beyond the default retention period, the correlation between custom audit records and platform logs is extremely valuable during the retention window. For customers that implement Analytics Streaming or external log retention, the value becomes even greater, enabling long-term traceability across multiple logging systems.

when refactoring entities between espaces, manual database scripts are required to migrate data to the new physical entity

Hi Team, While I was working in a project it got stroked me. Whenever I copy paste the text inside an expression or property field of a widget or Entity column names creation etc., lot of use cases. But the system is always wanted me to enclose double quotes manually. then I thought what if it auto enclose double quotes whenever i paste the text ? It might be a small thing but Definitely it will improve the user experience of the studio. Thanks.

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

I would like to be able to use HTML content in the email body in Reactive apps.Html content is needed to sent emails with a nice layout from Reactive apps.Expressions in Traditional Applications have the "Escape Content" attribute. When you set it to "No" a mail sent by a Traditional Application is delivered as a HTML Document. This is not possible in Reactive applications.The HTML Element can also not be used in an email in Reactive app.The only current solution would be, to create a Traditional Application just for sending the email and provide a public EmailSend-Method. But that is a lot of overhead just to send a mail.

It would be nice to have an option to clone/duplicate an application in Service Studio in the application detail view like we have the option to edit and remove.And also it would be nice to have the option to do the same to the modules inside but as an option.

 Problem : When an ODC environment is configured to use the ODC Cloud Connector, all REST integrations must use https://secure-gateway: as the base URL and pass the real target URL as a custom Host header. Since the secure gateway URL is the same across all environments, it adds no configuration value — yet it must be stored as a Setting, cluttering the Settings list with a technical implementation detail that developers never need to change. Idea : When the ODC Cloud Connector is active for an environment, ODC should recognize the Host header as the effective base URL for that integration and surface it in the Settings tab instead of (or in addition to) the raw base URL. This way, developers configure the meaningful value (the real target URL) and the platform handles the secure gateway routing transparently. Benefits : Cleaner Settings list - no noise from gateway URLs that never change Easier onboarding - developers configure what they understand (the real API URL), not infrastructure details. Consistent with the spirit of Settings as environment-specific, meaningful configuration values.