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.

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.

OutSystems provides strong local debugging (breakpoints, step‑through execution) and logs, and in ODC it already supports distributed traces at a technical level. However, from a developer’s point of view, there is still a significant gap between raw observability data and actionable troubleshooting. I’m proposing a developer‑centric, end‑to‑end request trace experience that makes it easy to understand what happened for a single user action: from the UI event, through server logic, to database operations and external integrations, without manual correlation. Service Studio debugging works well within a module, but once a request crosses: UI → Server Actions Aggregates → Integrations Async flows / Timers developers must manually jump between: Debugger Logs Integration error screens External system logs This fragmentation slows down root‑cause analysis and increases support effort, especially for intermittent or environment‑specific issues. Logs show facts / data, but not context. Logs record events, but: Developers must manually infer which UI action triggered which server/integration call Correlating logs across layers requires custom correlation IDs or naming conventions Performance issues often require guesswork to identify the slow component Traces technically capture request lifecycles, but developers don’t yet have a single, intuitive “story view” of a request that ties everything together in a one‑click request trace view that: Starts from a user action (e.g., button click, screen load) Shows the full execution chain across: UI action Server actions Aggregates / queries Integration calls Async operations (where applicable) Presents timing, failures, and context in a single timeline This is not about adding more logs, but about connecting existing observability data into a developer‑friendly narrative.

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?

 The Problem Currently, the "Create Entity Actions Wrappers" (CRUD actions) feature in Service Studio follows a static, hard-coded template. While this is helpful for rapid prototyping, most professional enterprise projects require specific architectural patterns that the default scaffolding doesn’t support. As a result, developers must manually wrap every generated action to include: Audit Trails: Automatically filling CreatedBy or ChangedAt attributes. Standardized Exception Handling: Ensuring specific UI or Log messages are triggered. Validation Logic: Checking for business rules before execution. Naming Conventions: Adhering to specific project-wide naming standards for wrappers. This leads to a significant amount of repetitive, manual work every time a new entity is created, increasing the risk of human error and architectural inconsistency across the team. The Proposal The introduction of a Custom CRUD Pattern configuration within Service Studio (at the Application or Environment level). This feature would allow architects to define a "Blueprint" or "Template" for CRUD generation. When a developer right-clicks an entity and selects the option to generate actions, Service Studio would check for a defined custom pattern. If found, it would generate the actions based on that template instead of the default OutSystems standard. Key Capabilities: T emplate Definition : Define a standard flow for Create, Update, and Delete actions. For Validation actions as well, for example would automatically check if the mandatory attributes are not empty. Placeholder Support : Use variables for Entity names or attributes within the template. Boilerplate Logic : Automatically include logic like "GetUserId()" or "LogRecord" in every generated action. Architecture Alignment : Ensure all entities immediately follow the project's "Good Practices" without manual intervention. The Goal The goal is to move from "Standard Scaffolding" to "Architectural Scaffolding." This would significantly speed up the development of new entities, ensure the entire team follows the same patterns from day one, and reduce the technical debt caused by inconsistently wrapped CRUD Actions. Ultimately, both options would exist simultaneously. The idea is not to replace, but simply to add a new option.

Hi Outsystems Team, I'm currently facing an issue where Service Actions do not receive the full set of client cookies , while Server Actions do. This limitation prevents the use of HTTPRequestHandler.GetCookie / SetCookie inside Service Actions in real scenarios. 📌 Problem When a request reaches a Screen Action or Server Action, all browser cookies are forwarded to the action's execution context. However, when calling a Service Action, only a small subset of platform‑managed cookies (e.g., UserId, TenantId, etc.) is available. This means: Custom cookies created by the application never reach the Service Action. HTTPRequestHandler inside a Service Action cannot read or modify these cookies. Some patterns related to authentication, tracking, and user context become difficult or impossible. 🔍 Expected Behavior Ideally, a Service Action should be able to: Receive the same full cookie set that Server Actions receive. Support HTTPRequestHandler.GetCookie and SetCookie. Allow more advanced use cases such as: Authentication extensions Cross-app user context sharing Tracking / analytics A/B testing Custom session or preference handling 🎯 Why This Matters Many modern architectures rely on Service Actions as: Shared reusable service layers Abstraction layers across multiple applications Integration or cross‑module processing points Centralized logic for authentication, tracking, and user context Without access to client cookies, these Service Actions become: Harder to design Less reusable Less aligned with real-world requirements This directly affects large-scale multi-app environments. ❓ Questions for OutSystems Is there a recommended way to forward all cookies to a Service Actio Is this a platform limitation or an intentional design restriction? Is there any roadmap to allow Service Actions to access the full cookie context? For now, we rely on a Server Action to read the cookies and pass them as input parameters. Is there a better official workaround? 💡 Additional Notes We do not need to modify platform-managed cookie. We only need to access custom cookies generated by the application. Everything works perfectly in Server Actions — the limitation occurs only at the Service Action layer. 🙏 Conclusion I would like to propose a feature that allows Service Actions to: Receive all client cookies, or Optionally specify which custom cookies should be forwarded This would make Service Actions far more flexible and suitable for real-world multi-application use cases. Any insights, confirmations, or guidance from the community or OutSystems staff would be greatly appreciated. Thanks in advance!

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?

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.

To put it simply and directly: It would be great to be able to provide Mentor with a screenshot of a screen built in Figma. Who knows, maybe the Mentor can help create amazing projects with that.