Add a way to filter the logs by excluding keywords. Use case : one of our process calls an external API using ArdoHTTP and every call results in a SLOWEXTENSION log, thus flooding the general log with pages of useless logs. This makes trying to find significant logs very difficult and time consuming. Being able to filter out by keywords, ie SLOWEXTENSION, would solve this issue.

Dear OutSystems Training and Certification Team, As the OutSystems platform continues to dominate the enterprise low-code market, more organizations are leveraging it to build highly visible public-facing applications, B2C portals, and marketing sites. Because of this shift, Search Engine Optimization(SEO) has become a non-negotiable requirement for many development teams. I am writing to formally propose the creation of a new specialization badge: Outsystems SEO Specialist. These specializations would validate the developer's ability to navigate the unique SEO challenges present in single-page applications(SPAs) on both Outsystems 11 and ODC, covering critical platform-specific implementations such as: Configuring clean SEO friendly URLs and site rules Integrating third-party pre-rendering services like prerender.io effectively. Managing crawlability sitmap.xml and robots.txt with the constraints of ODC and CDN layers. Optimizing core web vitals and DOM loading structures specific to reactive applications. By creating this badge, OutSystems will empower developers to build applications that are not only highly functional but also highly discoverable. Thank you for your time and continued effort to expand the ecosystems learning path Best regards OJJallow

Maintaining accurate, up-to-date documentation remains a challenge in enterprise environments — especially as applications evolve and team members change. While tools such as OutDoc provide valuable metadata-based documentation (e.g., structural elements, entities, modules, dependencies), there is an opportunity to extend documentation capabilities further using AI within the platform itself. I would like to propose native AI-generated documentation that goes beyond structural metadata and instead leverages the platform’s understanding of: Application logic flows Business rules and decision paths Integration intent and usage patterns Architectural layering Cross-module interactions Rather than simply listing components, the AI could generate contextual explanations such as: What the application does functionally How key processes are orchestrated Which integrations are critical and why How data flows across modules Where architectural boundaries exist This could live within the application overview, Service Studio, or a dedicated Documentation view — refreshable on demand and editable as needed. Importantly, this would add value not only for future platform directions, but also for the large base of existing OutSystems 11 (O11) applications running in production today. Documentation drift and knowledge loss are challenges that exist now, and having AI-assisted documentation available in O11 would provide immediate impact for enterprise teams. Many teams already experiment with exporting artifacts and using external AI tools to generate higher-level documentation. I recently explored this approach externally as a proof of concept: 👉 https://www.acceleratedfocus.com/post/bringing-clarity-to-undocumented-outsystems-code-with-ai Embedding this capability directly into the platform would: Improve developer onboarding Reduce knowledge loss Support governance and compliance Accelerate modernization initiatives Strengthen long-term maintainability This would not replace structured metadata documentation tools like OutDoc, but would complement them with AI-driven contextual understanding.

OutSystems is actively supporting integration of ODC and O11. Currently, the only way to consume logic from each other is to use a REST API. This is cumbersome and portentially unsafe. It would be much easier if the Platform allowed consuming Service Actions instead (which in essence are also REST methods, but easier to use). So O11 logic could consume an ODC Service Action, and ODC logic could consume an O11 Service Action. This would greatly enhance easy operability, and be secure out of the box.

If this is possible, I'm not seeing it. In O11 you can download a forge component without having to install it. In ODC this seems impossible. Why? I want to see what's in a forge component before committing to installing it in my environment. I have done this for as long as the forge exists. Why would you take away this option?

OutSystems works wonders when the API schema is stable, but many modern APIs return dynamic keys or partially populated objects, especially in integration-heavy and AI-driven scenarios. This creates friction because developers end up relying on custom JavaScript or complex workarounds just to render data cleanly in UI. What developers do today (pain): Build custom logic to extract unique keys Normalize JSON manually (fill missing attributes) Use JS to reshape payloads before JSONDeserialize Manage fragile UI rendering patterns for dynamic columns What I’d love to see improved in the platform: A native Dictionary/Map type for both client and server JSON tooling that supports deserialization into Maps for unknown keys A standard UI binding pattern (even without Data Grid) that allows dynamic columns safely This would reduce dependency on custom code and make OutSystems a stronger fit for modern API patterns. Curious, how are others handling dynamic keys today, and where do you see the biggest friction?

I would like to suggest two improvements that would significantly enhance the developer experience in OutSystems. Offline Development Support Currently, development requires a stable internet connection. In real-world scenarios (e.g., working while commuting or in low-connectivity environments), this becomes a major limitation. It would be highly beneficial to have an offline mode that allows developers to continue working on applications locally and sync changes once the connection is restored. Similar capabilities exist in other low-code platforms and greatly improve productivity. Real-Time UI Preview Without Publishing At the moment, verifying UI changes requires publishing the application, which slows down iteration. A real-time preview feature within Service Studio, where developers can instantly see UI/UX changes without publishing, would significantly speed up development and improve the overall workflow. Both features would reduce friction in daily development, improve efficiency, and align OutSystems with modern development expectations.

Hi, I've run into this a few times. I would like to have the ability to do a simple query with an IN clause, without having to rely on advanced queries. It should accept a list of Identifier. Today we do ( from an aggregate perspective): SELECT * FROM {TASKS} WHERE id = 1 or id = 2 or id = 3 But it would be really awesome if we could do SELECT * FROM {Tasks} WHERE id in (1,2,3) This allows us to do some pretty cool stuff with Lists setc ( eg you can now shim some of the more advanced sql functionality without writing advanced queries). An example would be: myList = SELECT id from People WHERE OrganisationId = 2 SELECT * FROM {Tasks} WHERE personId = myList Which would be 2 actions, and somewhat faster/cleaner than the current way Writing an advanced query ( frowned up by my companies' best practices guide - and I've also found advanced queries tend to be annoying to manage ) Looping through myList and putting the outputs into another list, which is then passed around (this also has a few nasties - lots of DB hits (albeit small ones), and refreshing this with paging is a pain

Implement an active Artificial Intelligence prompt directly integrated into Service Studio / ODC Studio, capable of analyzing OML files to detect issues, suggest improvements, and propose corrections , both automatically and through clear, detailed explanations of the proposed solutions . The idea is to allow developers to select a module or a set of elements (Actions, Aggregates, Entities, UI, integrations, etc.) and request an intelligent analysis that can: Identify logic, performance, security, and best-practice issues Suggest architectural and code readability improvements Clearly explain the root cause of each issue and the recommended solution Optionally apply automatic fixes or generate assisted refactoring suggestions An initial approach could involve exporting the OML for analysis by an external AI model (such as ChatGPT or Claude). However, the key differentiator would be having this capability natively embedded within the Studio , removing friction from the development workflow and improving application quality directly during development. Modern development tools already leverage AI for code review, refactoring, and optimization , delivering measurable gains in productivity and code quality. Bringing this capability deeply into the OutSystems platform would deliver significant value to developers , reinforcing OutSystems’ position as a leader in intelligent, AI-assisted low-code development.

In Reactive Web applications, it is common to have multiple front-end modules within the same application. Currently, Client Variables are scoped to a single module, which creates challenges when we need to share session-like data across modules. A common workaround is to centralize these variables in one module (_CW) and expose them through public client actions. While this approach works, it introduces some limitations: It increases complexity It requires additional control over events to retrieve the variable It cannot be used in Aggregates or Data Actions, since client actions are not supported in those contexts, even though module-level client variables are My suggestion is to introduce the ability to mark Client Variables as "Public", allowing them to be accessed across modules via references, similar to how public elements (e.g., actions, structures) are exposed today. This would enable: Direct access to shared client state across modules Cleaner and more maintainable reuse Elimination of unnecessary client actions and events used to retrieve values Consistent usage of client variables in UI logic and data-fetching layers This improvement would simplify cross-module state management and reduce the need for workarounds, especially in larger applications with multiple front-end modules.