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

The new option to publish with an added message is very nice, but too often I forget to click the dropdown arrow and accidentally Publish normally. Because there is no way to add a message after already publishing, this can get quite annoying. I suggest a simple extra configuration checkbox in the Service Studio Preferences to optionally change the "with Message" option to be the default. When enabled, Normal publish should still be available through the dropdown arrow.

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

I would like to suggest adding a microphone/voice-input option to Mentor in ODC Studio. Currently, developers interact with Mentor by typing prompts or commands. It would be highly useful to have a microphone button that allows developers to speak their requirements directly, with speech automatically converted into text and submitted as the Mentor prompt.

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.

 The Problem When an External Logic component is published to the Forge today, the author uploads a pre-compiled binary. A git repository link can optionally be included, but it is purely decorative, OutSystems does not verify any relationship between the linked source and the uploaded artifact. This means that as a consumer, when you install an external logic Forge component, you are executing code you cannot verify. You are trusting the author's word that what they linked on GitHub is what's actually running in your tenant. This is a real supply-chain risk — even with good intentions, a compromised account, a build-time dependency swap, or a simple mistake can result in consumers running code that doesn't match the published source. The Proposal Require that External Logic components submitted to the Forge are cryptographically linked to a public git repository at a specific commit, and that the submission process enforces this linkage — not just documents it optionally. The flow would look like this: The publisher develops and uploads their External Logic to their tenant as today (nothing changes here) When submitting to the Forge, they are required to provide a public git repository URL and a pinned tag or commit SHA that corresponds to the uploaded binary The Forge stores a SHA-256 checksum of the uploaded artifact alongside the source reference Consumers can inspect the source at the pinned commit, and optionally build it locally to verify the checksum matches what they'll be installing This doesn't change the upload mechanics, it adds an auditable envelope around what's already there. This is the same trust model used by mainstream package ecosystems: go install github.com/user/repo@v1.2.3 — builds from source at a verified tag cargo install --git — fetches and compiles from a git ref crates.io — stores checksums and optionally verifies builds server-side Why This Matters Transparency: consumers know exactly what code runs in their tenant, down to the commit Supply-chain integrity: eliminates the "binary black box" problem; no more trusting an uploaded artifact blindly Community accountability: published source is public and auditable; the community can catch issues before they spread O11's Integration Studio was transparent by design, you could open an XIF and see exactly what was there. ODC External Logic moved us forward in capability but took a step back in auditability. This proposal closes that gap, in a modern and supply-chain-secure way.

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

 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.

When selected, Mentor should automatically receive the error message along with the relevant application context, including the affected Screen, Action, Logic, Entity, expression, and dependencies.

While OutSystems provides strong AI capabilities for visual workflows and architecture, UI/Front-End customization often requires writing custom JavaScript and CSS. We propose integrating an inline AI Assistant into the JS and CSS code editors—not just to write code, but to actively enforce OutSystems best practices and offer native low-code alternatives. Key Capabilities: 1. Best-Practice Guardrails & Alternative Recommendations: - Identifies when custom JavaScript can be replaced by native visual logic or OutSystems UI client actions, suggesting low-code alternatives before code is written. - Flags heavy DOM manipulations or inline styles that might violate screen lifecycle patterns, performance guidelines, or maintainability. - Recommends using existing OutSystems UI CSS variables and utility classes instead of writing custom CSS rules. 2. OutSystems-Context-Aware JavaScript Assistance: - Auto-completes client-side logic using $parameters, $actions, and OutSystems JS APIs. - Assists with common front-end tasks like data transformations and third-party JS library initializations. 3. Smart CSS & Layout Assistant: - Converts natural language descriptions into clean CSS. - Flags CSS rules that might break OutSystems responsive layout systems.