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!

Currently, in OutSystems Service Center > Factory > Modules > [Module] > Operation tab, users with "Open" and "Debug" permissions can view essential settings like Audit Stack Display, Run Mode, Debug Mode, Deployment Zone, and Light Logging. However, the critical "Light Process Execution" checkbox—which enables lightweight BPT for improved throughput—is not visible or determinable. This checkbox is shown in full admin views (first attached image), but hidden for Open/Debug users (second attached image), preventing developers from confirming if Light BPT is enabled without elevated access. Requested Feature:Display the "Light Process Execution" setting (checked/unchecked status) in the Operation tab for any user who can access module details via Open/Debug permissions. This ensures consistency: if a user sees module operations, all relevant toggles should be readable. Business Impact: Developers troubleshooting performance can't verify Light BPT without admin help, slowing debugging in teams with role-based access. Promotes self-service in Service Center, aligning with OutSystems' low-code efficiency. No security risk, as it's read-only visibility matching existing fields like Debug Mode. Steps to Reproduce: Log in to Service Center with Open/Debug-only permissions. Navigate to Factory > Modules > [Any module with Light Process]. Go to Operation tab—note "Light Process Execution" is absent. Please prioritize this for better module visibility in O11

Currently, the OutSystems UI stylesheet applies a box-shadow effect through :focus when accessibility features are enabled. As a result, the focus indicator is shown both for keyboard navigation and mouse interaction. It would be preferable to use :focus-visible instead, so the focus indicator is only displayed when it is relevant, namely when users are navigating with the keyboard or using assistive technologies. This would provide a more appropriate default behaviour, improving the experience for mouse users while preserving a clear and accessible focus state for keyboard navigation.

Implement a "Conflict-Free Data Replicated Type " (CRDT) based editor that allows two developers to work on the same screen or logic flow simultaneously, seeing each other's changes in real-time without needing a manual merge

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.

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.

 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.

Currently, if we define a Sorting by an attribute, that sorting becomes unresponsive after introducing a Group By in the aggregate, as the sorted attribute is no longer part of the aggregate output . This does not raise any errors or warnings in the TrueChange Tab or any signaling in the workspace. I find that this is an easily overlooked situation that can lead to unexpected behavior or inconsistent results. I suggest the implementation of a typical Outsystems background validation that triggers a warning (written on the TrueChange Tab and a visual cue on the aggregate) whenever the aggregate's sorting references attributes that are not part of the aggregate output after a Group By, ensuring consistency and preventing silent issues.

ODC forge components are NOT included in you "Asset Count" on your profile, only OS11 force components. They should be included.