Hello, community! 👋 Having worked with OutSystems over the past few years—surviving the nightmares of broken references and monolithic architectures in O11, and now exploring the isolation of microservices and the AI Agent Workbench in ODC—I started reflecting on the next evolutionary leap for our platform. OutSystems Mentor already helps us generate screens and initial logic from prompts, which is fantastic. But what about large-scale maintenance and refactoring? Our beloved TrueChange is brilliant at pointing out where the application broke. If I change the signature of a core Server Action (e.g., changing an Input from Text to a Record/Structure) or delete an attribute from an Entity, TrueChange turns everything red in the Consumers. But I still have to go into 20 different modules and fix the mapping manually. The missing feature today: TrueChange Auto-Healing (AI Semantic Refactoring) What if ODC integrated an AI engine directly into TrueChange that didn't just point out the error, but wrote the fix automatically for your review? How it would work in practice: The Trigger: You change the return of an API or the structure of an Entity in your Producer module. The Analysis: The AI Auto-Healing engine detects that 15 Consumer apps broke. Instead of just throwing errors, the AI analyzes the semantics of your change. The Action: The engine scans the Server Actions and Data Actions of the consumers and rewrites the mapping logic (adding Assigns, converting data types based on context, or modifying Aggregates). The Code Review: In ODC Studio, you get a "Pull Request" style notification. You see a visual diff (before/after) of the logic altered by the AI across all consumers, and you just click "Accept All" or reject and adjust it manually. This would transform the platform from "Low-Code" to "Zero-Maintenance Code" at the architecture layer.

 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.

In ODC we should be able to open external logic files downloaded from Forge to check the code inside. Without knowing what is being done, we are just trusting in the actions comments without knowing exactly the logic inside and leading to possible privacy and security risks. O11 Integration Studio was more transparent on this. It was also more simpler and quick to create extensions.

I would like to propose the development of an API that allows integration with CI/CD tools to check for unused dependencies in an application. This API would provide a boolean value indicating whether there are any unused dependencies, enabling automatic detection during the CI/CD pipeline. By integrating this API into the CI/CD workflow, developers can easily identify and remove unnecessary dependencies, improving application performance and reducing resource consumption early in the development process.

Please add a native, fully supported platform feature to move an entity from one module to another without losing data. This feature should preserve primary keys, foreign keys, references, and runtime data, and it should update dependencies safely across producer and consumer modules. It should also support impact analysis and validation before applying the change, so teams can refactor module boundaries with confidence.

Just as all other elements, the custom exception could be public so that on consumer espaces you can have error handling for specific custom exceptions of the producer espaces. Showing what kind of exceptions are thrown in the tooltip of a user action would also be a good improvement

The idea of one general unit of measure to rule them all does not work well for a cloud based SAAS platform. Note, this idea is specifically focused on ODC. Looking at one of the most popular ideas submitted https://www.outsystems.com/ideas/14656/charging-1-ao-for-static-entity-is-not-worth-it/ it's clearly evident that using AOs as a measurement does not align with customer expectations. Static entities are one great example but it doesn't end there. The frustration with this pricing model likely stems from 2 things: The service/convenience (remembering the basis is SAAS) is not worth the actual cost (AO) The service cost does not make sense given the infrastructure/software required for OutSystems to provide it. e.g. what it costs OutSystems to provide this is significantly less than what they are charging customers (large margins). With that out of the way, the actual idea would be to abandon the AO cost model and adopt one that is more granular and tied closer with what we see from the SAAS cloud provider market. As an example, if I want to expose a REST API on AWS, I don't pay per endpoint because that makes no sense. Could AWS charge that way? Sure. The reason they don't and the same reason other cloud providers don't is because it doesn't scale because an endpoint infrastructure cost. To list things that don't seem to scale with AO pricing: AO per screen Static Entities Entities Charging per API method whether its creation vs consumption Custom defined events I get that the AO unit of measure is simple and changing it means buying in to more complexity from the OutSystems perspective. The overarching need to buy in to the complexity though IMO is that it steers customers away from using the platform as intended and as a result pushes that complexity burden down to the customers. That seems to be very contrary to the mantra of what OutSystems represents with being a low code platform. I feel its important to state that this has nothing to do with OutSystems right to make a profit or what that profit is. It should wholly be expected that OutSystems has a profitable margin on any service they offer as long as customers are willing to pay for it. The goal is simply to: Encourage customers to adopt OutSystems services broadly by avoiding prohibitive pricing structures Increase pricing transparency and as a result improving the ability to forecast/budget scaling cost Adopt a pricing model that customers can more easily reason about

Allow changing variable values while debugging

 Problem Monitoring timers usually requires opening Service Center and checking logs manually. For business users or support teams, this information is not always easy to access. How this suggestion can help A reusable Timer Monitor component would allow teams to display timer status directly inside internal admin screens. Implementation example A Forge component or native widget could show: Timer Name: Sync_Service NowLast Run: 22/05/2026 08:00 Status: Success Duration: 2m 35s Next Run: 22/05/2026 09:00 Last Error: - It could also include filters by application, module, status, and execution date.

Ai mentor should have the same capability of the new mentor in odc service studio, that could allow us not only observe the Tech Debt but take immediate action and solve It using the chat like mentor to prompt and tweek the findings!