In ODC, as in O11, e should be able to know which logic is being applied inside an app (for example to find from errors are coming from), for example in the (System) app. When we try to open a protected app, it does not even open in a read only mode:

Most of the times I need to open Service Studio just to check code and I do not need to get the references. It would save a lot of time when we just want to check the code and not change anything

Many REST services implement sending files, documents etc. by having a body with multipart/form-data. There are many questions on the forum about this, e.g. here , here and here . Unfortunately, the OutSystems Platform lacks native support for this, leading to workarounds like this Forge Component or "manually" modifying the request data in the OnBeforeRequest, which leads to things ugly code like this:(Yeah, that's mine :).)So it would be a great addition to the Platform if it had native support for multipart/form-data for REST services, at the very least for consuming them. That would make our lives just a tad bit easier!

OutSystems works wonders when the API schema is stable, but many modern APIs return dynamic keys or partially populated objects, especially in integration-heavy and AI-driven scenarios. This creates friction because developers end up relying on custom JavaScript or complex workarounds just to render data cleanly in UI. What developers do today (pain): Build custom logic to extract unique keys Normalize JSON manually (fill missing attributes) Use JS to reshape payloads before JSONDeserialize Manage fragile UI rendering patterns for dynamic columns What I’d love to see improved in the platform: A native Dictionary/Map type for both client and server JSON tooling that supports deserialization into Maps for unknown keys A standard UI binding pattern (even without Data Grid) that allows dynamic columns safely This would reduce dependency on custom code and make OutSystems a stronger fit for modern API patterns. Curious, how are others handling dynamic keys today, and where do you see the biggest friction?

Currently, OutSystems only allows limiting the total number of simultaneous process executions across the environment. There is no way to restrict concurrency per process type, which can cause problems when a single process spawns many instances. For example, starting 1000 BPT processes of the same type can consume all available execution slots, effectively blocking other processes from running. A per-process concurrency limit would allow developers to define a maximum number of simultaneous executions for each process (e.g., 4 instances at a time). Additional instances would automatically be queued until a slot becomes available. This feature would provide: Better control over resource usage for high-volume processes. Reduced risk of process starvation, where other processes cannot execute because one process is using all slots. Simpler queue management without custom throttling logic. Introducing per-process execution limits would make process orchestration more predictable and efficient, allowing developers to safely run multiple processes in parallel without one process dominating the system.

Under 'Exceptions' in ODC Studio/Service studio. Allow the creation of folders so User Exceptions can be grouped

OutSystems certifications are highly valued by developers and organizations worldwide. However, unlike many other global certification programs (e.g., AWS, Microsoft, IBM), OutSystems currently does not issue Open Badges for its certifications. Open Badges are digital credentials that embed metadata into badge images, making them verifiable, shareable, and portable across platforms. They are standardized by the 1EdTech Consortium (formerly IMS Global Learning Consortium) and widely adopted in education and industry. https://www.imsglobal.org/spec/ob/v3p0/ By enabling Open Badge support for OutSystems certifications, the platform can: Increase visibility and recognition of certified professionals Improve integration with digital portfolios and LinkedIn profiles Align with international standards for credentialing Enhance motivation and engagement among learners Implementation can be streamlined using existing platforms like Credly, which many organizations already use for badge issuance. The cost and operational burden are moderate, and the benefits in branding, community engagement, and learner experience are significant. We hope OutSystems will consider adopting Open Badges for its certification programs to further empower its developer community and strengthen its global presence.

Adding Native Semantic Search capabilities within the OutSystems platform. This would allow developers to implement search features that understand the user's intent and the contextual meaning of their queries. Key Features: Vector Embedding Support: Built-in capability to generate and store vector embeddings for database records directly within the platform. Natural Language Queries: Users can search using phrases like "fresh products near me" instead of specific product names, and the system should understand the intent. Multilingual Semantic Search: Since many apps are regional, the search should understand queries in local languages like Malayalam and map them to relevant results even if the keywords don't match exactly. AI Orchestrator Integration: Seamless integration with OutSystems AI Orchestrator to leverage models like Google Gemini or OpenAI for retrieving search results. Why it matters: Integrating semantic search will revolutionize how users interact with data in OutSystems apps. It improves user experience by providing more relevant results, which is critical for the success of systems.

Add native Passkey authentication support to OutSystems, enabling secure, passwordless login using platform-level passkeys (FIDO2/WebAuthn). Passkeys are becoming an industry standard (and for good reason) as they have multiple advantages over traditional authentication methods. From Fido Alliance: This could technically be implemented via a Forge component, but given the complexity and security criticality it would be much better if the platform handled it.

Right now when a user navigates to a URL that is not associated with a page or the URL for a page that has been removed, you end up at an ugly 404 page located in /customHandlers/ As seen in this forum post you can edit the custom Handler's page directly, but my understanding this would change it for all apps, and doesn't seem possible in a Cloud environment. It would be nice if we at least had the option of configuring the 404 page, similar to the Invalid permissions or Internal error pages. Especially if one of the inputs of this page was the originally attempted URL, meaning we could redirect the users if they were attempting to go to an old screen that was removed, but the content is now elsewhere. Thanks!