Hello Our organization currently maintains a large-scale application developed using OutSystems Traditional Web. At present, we lack a formal mechanism to monitor the real-time volume of active user sessions within the Production environment. Acquiring this data is essential for optimizing production support operations and determining appropriate schedules for release management. Thank you.

 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.

Currently, it is not possible to conditionally add or remove an HTML attribute using the Attributes property. The only way to achieve this behavior is through custom JavaScript. It would be very useful to have the ability to conditionally render an attribute based on an expression, similar to how the Value property currently supports expressions. This would allow developers to avoid rendering empty or unnecessary attributes in the generated HTML. The feature could work as illustrated below: This enhancement would be particularly valuable for accessibility requirements, enabling developers to more easily implement dynamic ARIA attributes and other accessibility-related properties, ultimately improving development efficiency and speeding up delivery.

When a Client Action is assigned as an event handler, it would be helpful to have a "Go to Event Handler" option that navigates directly to the associated Client Action. This would improve navigation and speed up development by making it easier to inspect and edit event handlers. The option could be exposed either through: The event handler dropdown menu A right-click context menu on the event property This enhancement would improve developer productivity and reduce the time spent locating event handler implementations.

Hi, When working with multiple tenants, we often encounter situations where a query returns no results or unexpected results simply because the wrong tenant is configured. This can lead to unnecessary time spent troubleshooting the query itself, when the actual issue is that the active tenant is not the one we intended to use. To my knowledge, the only way to check/change this is here: Module menu: Opens this pop-up: From a developer experience perspective, it would be helpful if the currently active tenant was made more visible when building or testing queries. For example, the active tenant could be displayed/editable directly within Aggregate and SQL nodes, making it immediately clear which tenant is being queried: This small enhancement could help reduce confusion, save development time, and improve the overall developer experience when working in multi-tenant environments. Thanks in advance. Regards, Ricardo

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

It's been years since dark mode was introduced, yet the icons in the list are still barely visible in Traditional. Could we make the icons the same color as the text or change the widget for the one in react? Previous image is traditional icon selection. previous image is react icon selection.

Using OutSystems Semantic Search for community pages such as Forums, Ideas, and Forge brings a step change in how community members discover knowledge and reusable assets across the ecosystem. Traditional keyword search relies on exact matches, which often leads to incomplete or irrelevant results, especially in large content bases like community discussions, ideas and Forge components. Semantic Search, by contrast, understands intent and context, allowing users to find relevant answers even when terminology differs from how content was originally written. For the OutSystems community, this has a few clear benefits. First, it significantly improves discoverability. Community members can find the right forum threads, idea submissions, or Forge components without needing to know the exact naming or tags used by the author. This reduces friction and increases successful self-service. Second, it increases reuse and reduces duplication. Better search results mean developers are more likely to find existing Forge components instead of rebuilding similar functionality, and more likely to engage with existing Ideas rather than creating duplicates. Third, it improves community engagement quality. When users quickly find relevant discussions or solutions, they are more likely to contribute back, vote on Ideas, or refine existing answers instead of starting new fragmented threads. Finally, it future-proofs the community knowledge base. As content volume grows, semantic understanding scales far better than keyword-based approaches, ensuring that search quality does not degrade over time. In short, Semantic Search turns the community from a static repository into an intelligent discovery layer, making knowledge, ideas, and reusable components easier to access, reuse, and extend.

A centralized Developer Cheat Sheet for OutSystems Developer Cloud (ODC) would greatly help both new and experienced developers quickly understand and adopt the platform. Similar to the existing O11 cheat sheet, this should provide a concise overview of key ODC concepts, architecture, development flow, best practices, and differences from O11. It would serve as a quick reference guide to help developers ramp up faster and become productive in ODC projects with minimal learning curve. This resource would be especially useful for: New developers getting started with ODC Experienced O11 developers transitioning to ODC Teams looking for a quick refresher on core concepts Providing such a cheat sheet would improve onboarding efficiency, reduce confusion, and accelerate project delivery within the ODC ecosystem.