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.

As we are now having folders everywhere, please do the same for service studio main screen. This way applications can be grouped by context.

In OutSystems Platform publishing is like comitting your changes to Version Management. It would be extremely helpful to be able to add comments on the 1 Click Publish process. This would be even more flexible if one could drill down these comments by changed object (webscreen, webblock, action, webreference action, etc)

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.

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.

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

I would like to see a built in midnight/dark theme for service studio. Something that is a little easier on the eyes when working the night shift.Looked around but couldn't find anything to suggest this is a duplicate, but let me know if it is.

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.

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.

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.