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 moving from DEV to QA it is asked to provide site properties or use the default ones. It would be nice to do this for REST and SOAP urls as well. We had a situation where the WSDL (and we didn't know) was pointing to PRD. We changed it on DEV to so that the intergraded SOAP was pointing to the development version. When deploying to QA we considered that this would point to DEV again. But it took the URL from the original Url WSDL. So it was pointing to PRD. When deploying from DEV to QA the siteproperties are shown and can be defined. It would prevent errors to do this for consumed integration REST and SOAP URLs as well. Especially for SOAP. For rest it is possible to define the base URL and choose DEV so that when deploying to QA it's not suddenly PRD. For SOAP it seems not to be possible to provide a base URL Example

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.

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

Currently, AI helps generate code, but one of the biggest challenges in enterprise OutSystems applications is understanding existing applications. I would like to suggest an AI-powered assistant capable of analyzing an existing module and explaining: • Screen and module responsibilities • End-to-end business flow • Server Actions and Client Actions relationships • Dependencies between modules • Entities and data flow • Integration points (REST, SOAP, Events) • BPT processes • Timers and Scheduled Jobs • Security model (Roles, Permissions) • Reusable components usage • Architecture recommendations • Technical debt detection • Suggestions for SOLID and architecture improvements This feature would be extremely valuable when: - Joining an existing project. - Maintaining legacy applications. - Performing code reviews. - Onboarding new developers. - Supporting technical leads and architects. Instead of simply generating code, AI could become an intelligent documentation and architecture assistant, helping teams understand large enterprise applications much faster. This would significantly reduce onboarding time and improve productivity for development teams.

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.

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.