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.

Dear OutSystems team, the OutSystems Data Grid lacks an event to intercept the moment when the rows in the grid are loaded and ready to be manipulated. The Initialized event and the OnAfterFetch event do not guarantee that a cell or a row is loaded into the grid, so any action that needs to access the Data Grid data, for example, will most likely fail if used in this context. An example would be apply a specific CSS class only to specific cells given a combination of conditions on the cell's row data: the action in API_Styles will most likely fail, together with the ones in API_Rows and the Conditional Formatting of the columns is not powerful enough to add CSS classes only to specific cells in a row or in a column. Also by trying to intercept the loadedRows/collectionChanged event of the FlexGrid using a similar mechanism implemented for the OOTB events of the Data Grid, there is the possibility the first loading of the data is missed due to the handler being registered after the grid loaded the rows (I tried in this Forge component: https://www.outsystems.com/forge/component-overview/21664/raffaeles-data-grid-utilities-o11 ) I think having an OOTB DataLoaded event exposed directly by the Grid block would help in a lot of situation where there is the need to have the data loaded and accessible into the grid. Thank you for your time! Best regards, Raffaele Battipaglia

Provide a secure, built-in read-only data viewer for ODC Production environments, allowing authorized users to view entity records without creating custom screens or APIs. Benefits: Faster troubleshooting and support Reduced development effort