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.

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

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

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.

While learning and working with JavaScript inside OutSystems, I experienced a situation where an error in my JavaScript code was not indicated while I was writing it. For example, I declared an array using const and later tried to assign a new value to the array variable. I was not aware that this was an error, and the JavaScript editor did not provide any indication while I was writing the code. I only encountered the error when I tried to publish the application. As a developer who is learning JavaScript, it was difficult to identify the mistake without immediate feedback. My suggestion: It would be very helpful if the JavaScript editor in Service Studio could detect common JavaScript errors while the code is being written and indicate them visually, for example with a red underline or error marker. Hovering over the marked code could also display a short explanation of the error. This would allow developers to identify and correct JavaScript errors immediately instead of discovering them only during publishing. I believe this would improve the development experience, particularly for developers who do not have extensive JavaScript experience.

Currently, when viewing the version history of an item, selecting a specific version opens it in the current tab. To compare different versions, users need to first open the latest version and then manually navigate to the desired version. It would be helpful to add a context menu option (right-click) on a version entry, such as "Open in New Tab", allowing users to directly open the selected version in a separate tab. Benefits: Faster access to specific versions. Easier side-by-side comparison between versions. Improved user experience for reviewing changes and audit activities. Reduces the number of clicks required to navigate between versions.

 Current Situation When working on an application with multiple developers and multiple published versions, it can sometimes be difficult to understand exactly what changed between a previous version and the currently published version. OutSystems already provides version comparison capabilities, which are useful for inspecting differences. However, when a module contains many changes, developers may still need to manually go through different elements to understand the overall scope of the changes. I would like to suggest adding a “ View Changes ” option when opening a previous version of a module. For example, when selecting a previous version from “ Open Other Version ”, there could be an option such as: View Changes This would automatically compare the selected version with the currently published version and provide a clear, consolidated summary of all the changes between those versions. What Should Be Included? The change summary could cover different levels of the module, for example: UI / Screens Screens added, removed, or renamed Containers/widgets added or removed Container/widget names changed CSS classes changed Widget properties modified Screen Actions/Event Handlers added, removed, or modified Client Actions Client Actions added, removed, or renamed Logic modified Input/output parameters added, removed, or changed Variables added, removed, or modified Dependencies/references changed Server Actions Server Actions added, removed, or renamed Logic modified Input/output parameters changed Variables added, removed, or modified Dependencies/references changed Data / Entities Entities added or removed Attributes added, removed, or modified Data types changed Relationships or other relevant properties modified Module-Level Changes Module properties changed Public elements changed References added, removed, or updated Dependencies changed Other relevant module-level configuration changes Example If the current published version is Version 100 and a developer opens Version 95, clicking “View Changes” could display something like: Changes from Version 95 → Version 100 Screens ✓ HomeScreen - Container "MainContainer" renamed to "DashboardContainer" - CSS Class changed - New Button added Client Actions ✓ RefreshData - Logic modified - New input parameter added Server Actions ✓ GetCustomers - Aggregate modified - New filter condition added Entities ✓ Customer - Attribute "Status" added - Attribute "IsActive" changed References ✓ CustomerAPI - Reference updated Ideally, each change could be clickable so that the developer can directly navigate to the affected element and inspect the detailed difference. Why Would This Be Useful? This would be particularly useful when: Debugging : Developers can quickly identify what changed between two versions instead of manually inspecting the entire module. Code reviews : It provides a quick overview of the actual changes introduced between versions. Maintenance : Developers can easily understand when and where a particular change was introduced. Troubleshooting : If an issue appears after a particular publish, developers can quickly identify the relevant changes. Team collaboration : It becomes easier to understand changes made by other developers. Large applications : It reduces the effort required to inspect changes across complex modules. Overwritten changes : Sometimes a developer may unintentionally overwrite or replace existing code/logic while making changes. In such cases, being able to quickly see what was changed compared with an earlier version would be extremely helpful as a reference for identifying what was overwritten or modified. Rollback decisions : Before reverting to an older version, developers can clearly understand what changes would be affected. Related Existing Ideas / Clarification Before posting this idea, I searched the OutSystems Community to make sure there wasn't already an existing idea covering the same requirement. I found the existing idea “ History of change in Actions and Screens and compare with previous versions ”, which focuses mainly on maintaining history and comparing changes for individual Actions and Screens. There are also existing discussions around comparing a module with a previous published version, as well as functionality related to publish/change comments. However, my understanding is that the proposed idea is slightly different: The goal is not simply to compare two versions, but to provide an automatically generated, consolidated “View Changes” summary covering the entire module. This could include Screens, UI elements, Client Actions, Server Actions, Entities, References, Dependencies, and module-level changes , all in one easy-to-understand list. The existing comparison functionality could still remain available for developers who need detailed inspection. The proposed “ View Changes ” feature would act as a high-level summary layer on top of that , making it much easier to understand the overall changes between two versions. This is why I believe this could complement the existing version comparison/history capabilities rather than duplicate them.

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

 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.

 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.