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.

 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.

While working in Service Studio using Dark Theme, selected elements such as Assigns, Decisions, Aggregates, Actions, Loops, and Connectors can be difficult to identify, especially when: Screen brightness is low. Working with large and complex logic flows. Presenting or sharing screens during meetings. Currently, the visual difference between selected and non-selected elements is quite subtle, making it challenging to quickly locate the active element and follow the execution flow. Suggestion: Introduce a High-Contrast Selection Border for selected elements. When a node or connector is selected, display a thicker, high-contrast border (for example, bright cyan, yellow, or orange) around the element. This would make the selected element immediately stand out from the surrounding workflow, improving visibility, reducing eye strain, and enhancing productivity when working in dark environments or on large server actions. This enhancement would significantly improve the overall usability and accessibility of Service Studio's Dark Theme experience.

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

When building RAG pipelines in ODC against structured documents, the four native chunking methods treat all input as plain text. This works well for simple text stored in entity attributes but creates problems for documents that have structure: fenced code blocks, Markdown tables, and nested headings. A Markdown-aware chunking option would let developers preserve that structure during ingestion without needing a custom External Logic workaround. Three behaviours would cover most cases: heading path tracking so chunks carry their section context, code block atomicity so fenced blocks are never split across chunks, and table preservation so tables stay whole. The upstream Forge ecosystem already produces Markdown output via components like OmniDoc2MD . A native Markdown chunking method would complete that pipeline naturally. This is not a replacement for the existing methods. It is an additional option for teams whose documents have structure worth preserving.

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.

Currently in LifeTime, there is no easy way to identify which applications have bespoke (application-level) Content Security Policies configured. To check this, we must manually open each application and review its security settings in each environment. This becomes difficult to manage at scale, especially when CSPs are applied selectively across multiple applications and environments. It also introduces risk, as teams must rely on memory or manual tracking to know where custom CSPs have been configured. It would be highly beneficial to have: - A way to filter or list applications with custom CSPs in LifeTime Visibility per environment to understand where overrides exist - A clear indication of whether an application is using environment-level CSP vs application-level CSP This would significantly improve security governance, reduce manual effort, and help teams maintain consistent and auditable CSP configurations across their platform.