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.

Currently, when a mobile or reactive app client disconnects mid-request (e.g. user backgrounds the app, loses network, or a timeout occurs), OutSystems logs the following errors in Service Center as 500-level errors: "The client is disconnected because the underlying request has been completed. There is no longer an HttpContext available." "Failed to send request due to unexpected error" These errors are thrown deep in the ASP.NET/IIS pipeline by the ErrorNotifierModule, below the OutSystems application layer. This means developers have no way to catch or suppress them using OutSystems logic — not through OnException handlers, not through error handling in Client/Screen/Data Actions, and not through any pattern available in Service Studio. Why this is a problem: These errors are not actionable by developers — there is no OutSystems-level fix that prevents them They pollute the error log in Service Center, making it harder to identify real application errors (we currently have an average of 60.000 daily errors like these) They generate false alerts in monitoring tools and APM integrations that consume OutSystems error logs They cause unnecessary noise in production environments, particularly for mobile apps used on unreliable network connections What we are asking for: OutSystems R&D to implement one or both of the following: Suppress specific known client-disconnect exception types (e.g. HttpException with error code 0x800703E3) in the ErrorNotifierModule before they are written to the error log, since these represent expected network-level events, not application bugs Provide a configurable filter mechanism in Service Center or Factory Configuration that allows platform administrators to define error message patterns that should be downgraded (e.g. to a warning) or excluded from the error log entirely Expected outcome: Developers and operations teams can maintain clean, actionable error logs that reflect real application problems — without being forced to implement infrastructure-level workarounds outside the OutSystems platform.

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.

 Problem: There's no way to rate or review Forge components, making it hard to judge quality or reliability before installing one. Proposed Solution: Add a star rating and comment system to each Forge component page - visible in listings and search results. Restrict reviews to users who've installed the component, and let authors respond to feedback. Benefit: Helps developers choose components with more confidence, gives authors useful feedback, and improves trust across the Forge ecosystem.

I would like to suggest that applications relying on deprecated elements (marked as DEPRECATED_) be considered as technical debt in the AI Mentor platform. By considering applications that depend on deprecated elements as technical debt, we can prioritize their resolution and allocate resources to address them accordingly. This approach will help us ensure that the AI Mentor platform remains up-to-date, efficient, and aligned with industry best practices. Thank you for considering this suggestion. I believe that by actively managing technical debt related to deprecated elements, we can enhance the overall quality and maintainability.

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 forum has slowed down a bit recently, with fewer questions and answers over the past few months. Everyone is very busy, yet they still participate in discussions and provide answers. I think it would be a good idea to offer rewards—such as certification exam vouchers—to the top 10 contributors each month.

As we know, contact centres are underwater everywhere (as SNS24 in Portugal).The idea is to create a chatbot for FAQs that allow people to quickly get relevant information.We can use OutSystems.AI chatbot , integrated with the QnA service and integrated with some oficial knowledge bases (example: https://www.ecdc.europa.eu/en/novel-coronavirus-china/questions-answers ).Unanswered questions can be listed in a page, to be reviewed and added to the knowledge base, to make the chatbot smarter and smarter.The chatbot could then be highly improved if we allow humans to enter the loop and make the experience even smoother.

I would be great to be able to edit entity data (in addition to the ViewData functionality) inside Service Studio.As far as I know, there is no easy way to manually edit data for testing purposes.This is extremely helpful especially when bootstrapping data from Excel

The proposal aims to enhance the performance of the OutSystems built-in ListAppendAll function. Currently, ListAppendAll iterates over the source list using a foreach loop, invoking the ListAppend action on each iteration. This results in multiple dynamic array resizings, as each call to ListAppend extends the underlying array incrementally, leading to performance overhead due to repeated memory allocations and data copies. In contrast, in native C#, the List.AddRange method optimises this process by pre-allocating the required space in the underlying array in a single operation. It then efficiently inserts elements using Array.Copy, minimising reallocations and improving execution time. Implementing a similar bulk append mechanism in ListAppendAll would reduce memory overhead and improve performance. The attached files include the BenchmarkDotNet results and the code used for performance testing. Tested on .NET 4.8.1 and Intel Core i7 12800HX processor. While the code does not exactly replicate the OutSystems implementation, it follows a similar approach to demonstrate potential performance improvements.