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.

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.

 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.

In our project, we needed to use a switch to route logic across 20+ nodes. It works well, but the resulting flows can become very large and difficult to navigate. The existing node-alignment options help, but a general “Arrange Nodes” action in the right-click menu would make flows like these easier to keep readable. I understand that automatic layout is less trivial than it might seem. However, Mentor can already arrange a flow reasonably well when asked, so perhaps a similar approach—whether optimized specifically for this purpose or powered by AI—could be offered directly in the IDE through a right-click menu. An undo option would also be important. This would make arranging flows faster and more convenient during development.

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 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.

Currently, updating a single entity attribute in OutSystems often involves retrieving the entire record, modifying the required attribute, and calling the Update Entity action. It would be useful to have native partial update (PATCH-like) functionality, allowing developers to update specific attributes using the Entity ID without retrieving the complete record or writing Advanced SQL. Benefits: Reduce unnecessary database reads. Simplify development and improve maintainability. Prevent accidental overwriting of unrelated attributes. Potentially improve database performance.

Today, Agent Evaluations and their datasets can only be created and run from the ODC Portal. That keeps evaluation separate from the apps and agents we build, even though that's where test cases come from and where results are most useful. We'd like to be able to create and run evaluations at runtime, from OutSystems logic. This could be a REST API (like the Deployments or Build Operations APIs) or, ideally, built-in server actions that apps and agentic apps can call directly. Proposal Expose the following operations so they can be called from any app or agentic app: 1. Datasets: - Create a dataset for an agentic app and service action. - Add, update or remove test cases (inputs, expected outputs, expected tool calls). - Export/import using the existing JSON format. 2. Evaluations: - Create an evaluation with selected judge criteria (Correctness, Safety, Guidelines, Relevance, Tool Trajectory). - Start, cancel and check the status of a run. 3. Results: - Get the scores per test case and per criterion, and the run history. Benefits - Evaluation inside the product: datasets grow from real usage, directly from the apps where interactions happen. - Agentic automation: agents can create, run and analyze evaluations as tools. - Fewer workarounds: no need to log interactions and send them to external evaluators. - Governance: the same permissions as today (View/Manage Evaluations) apply, through service accounts or user roles, and every action stays auditable.