What we ran into We're running a pilot with Claude Code and the O11 MCP server in Service Studio, and it works well. But we quickly hit a governance question: we want agents to work in Development only, and we can't enforce that today. The agent simply gets all the developer's permissions. If a developer can publish to Test, so can their agent. LifeTime has no MCP setting. The write permissions setting lives in each developer's own Service Studio. Developers often have Service Studio open on both Development and Test. The agent only sees 127.0.0.1:, and none of the MCP tools say which environment it's connected to. So we can't build a reliable check on our side either. Agent changes are recorded under the developer's name, so you can't tell afterwards what an agent did on its own. Our only option now is to cut developers' own permissions on higher environments, and that's not what we want. What would help MCP setting per environment in LifeTime. Let an admin choose per environment: Disabled / Read-only / Read-write / Publish. Service Studio applies it at sign-in and developers can't override it. For example: Read-write in Development, Read-only in Test, Disabled in Production. Tell the agent where it is. Return the connected environment (name and hostname) in listApps or a separate tool. The agent can then confirm the target with the developer, and our own hooks can block actions in the wrong environment. Mark unattended agent publishes. When an agent publishes without review (the "Allow automatically merge and publish" setting), mark that version in Service Center and LifeTime as an agent publish. Changes the developer reviewed in Compare and Merge can stay under their name, as they are now. Why it matters Agents in O11 have real potential, but to use them safely we need central control in LifeTime, not settings and agreements per developer. These changes would make it much easier to start in Development and expand from there. We love to hear from you Are you already using the MCP server or other AI agents with O11? How do you keep agents out of the wrong environment, and which settings or team agreements work for you? Did we miss something, or would you solve it differently? Please share your experience in the comments, and vote if this matters to you too.

 Title Optimize GUID Storage in SQL Server for OutSystems Entities Problem In many OutSystems projects, developers use GUIDs to expose entity identifiers externally instead of exposing the internal Integer IDs. This is a common approach when identifiers need to be shared through APIs, URLs, or integrations. However, when these GUIDs are stored in SQL Server as NVARCHAR(36), they consume up to 72 bytes per value, compared with just 16 bytes when stored using SQL Server's native UNIQUEIDENTIFIER data type. This difference can have a significant impact on database storage and performance, particularly in applications with large volumes of data. Impact Storing GUIDs as NVARCHAR introduces several potential disadvantages: Increased database storage: Each GUID value requires up to 72 bytes instead of 16 bytes, increasing the size of table data. Larger indexes: Indexes containing these GUID columns require more storage, potentially increasing memory consumption and the number of pages SQL Server needs to read. Increased I/O: Larger indexes and data structures can lead to additional page reads and greater I/O requirements for queries. Reduced scalability: In tables containing millions of records, the additional storage can accumulate significantly, increasing database resource consumption and potentially infrastructure costs. These effects can become more pronounced when GUIDs are used in foreign keys, frequently queried columns, or multiple indexes. Proposed Improvement Introduce support for storing GUID attributes using SQL Server's native UNIQUEIDENTIFIER data type instead of representing them as NVARCHAR(36). Ideally, this capability would be supported natively by the OutSystems platform, allowing developers to benefit from SQL Server's more compact GUID representation without requiring custom database implementations or workarounds. The solution should preserve the ability to expose GUIDs through APIs and integrations using the standard string representation, ensuring compatibility with existing application requirements. Expected Benefits Reduced database storage requirements. Smaller indexes and potentially better memory efficiency. Reduced I/O overhead for workloads involving GUID-based lookups and joins. Improved scalability for applications with large datasets. Potential reduction in database infrastructure costs.

Problem / Current Situation Currently, implementing real-time audio and video calling in OutSystems Reactive Web applications requires significant manual JavaScript development and knowledge of WebRTC APIs. Developers need to manage peer connections, SDP offers and answers, ICE candidates, media streams, signaling, and connection lifecycle events. I recently faced this challenge while implementing a one-to-one video calling feature in an OutSystems 11 Reactive Web application. I searched OutSystems Forge for a reusable WebRTC component but could not find a suitable, easy-to-use solution. Proposed Solution Introduce an official reusable WebRTC component for OutSystems Reactive Web applications. The component should provide a simple visual and action-based interface so developers can implement audio and video calling without manually writing complex WebRTC JavaScript code. Proposed Features One-to-one audio and video calling. Local and remote video stream management. Microphone and camera on/off controls. Screen sharing. Incoming call notifications with Accept and Reject actions. SDP offer and answer management. ICE candidate handling. Connection status and error handling. Configurable signaling mechanism (OutSystems server actions or external signaling services). Support for OutSystems 11 Reactive Web and, if feasible, ODC. Expected Benefits Reduces development time. Makes WebRTC accessible to low-code developers. Avoids repetitive JavaScript implementations. Encourages reusable architecture. Enables developers to add video conferencing capabilities to business applications more easily. Conclusion A native WebRTC component would be a valuable addition to the OutSystems ecosystem and could help many developers build modern real-time communication applications more efficiently.

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

Problem / Opportunity OutSystems Developer Cloud (ODC) access and configuration can sometimes be unclear to platform users. Users may have access to the OutSystems platform but still be unable to access ODC due to permissions, subscription settings, or configuration requirements. Proposed Idea Introduce a centralized ODC Access Management and Troubleshooting feature that allows users to: Easily check whether their account is eligible for ODC access. Identify missing permissions or subscription requirements. Request ODC access directly through the platform. Receive clear error messages explaining why access is unavailable. Allow administrators to approve and manage access requests. Expected Benefits Improve user experience and productivity. Reduce support tickets related to ODC access. Simplify platform administration. Help organizations onboard developers faster. Provide greater transparency around ODC permissions and availability. Why This Idea Matters A seamless access experience is essential for developers to adopt and use OutSystems Developer Cloud effectively. By making access management more transparent and self-service, OutSystems can reduce administrative overhead and improve customer satisfaction.

Allow administrators to expose selected business entities and approved queries through a native MCP server, enabling AI assistants to securely retrieve and analyze existing OutSystems application data without requiring custom MCP tool development

When you have an exposed REST API with a lot of methods, it would be useful to be able to group them in folders, like you can do with actions. Same for large consumed APIs, would be useful to group the consumed methods in folders.

The new option to publish with an added message is very nice, but too often I forget to click the dropdown arrow and accidentally Publish normally. Because there is no way to add a message after already publishing, this can get quite annoying. I suggest a simple extra configuration checkbox in the Service Studio Preferences to optionally change the "with Message" option to be the default. When enabled, Normal publish should still be available through the dropdown arrow.

Introduce a personal dashboard where developers can track their OutSystems Community points in detail. It should display when points were earned, the activity that earned them, the points awarded, and a link to the original contribution. This would provide greater transparency into the scoring system, help developers understand their contributions, and motivate them to participate more actively in the community.