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

As we move toward Agentic AI in ODC, we are currently forced to choose between two paths for vector storage: External Vector DBs (Pinecone, Qdrant): Great performance, but introduces data residency/compliance hurdles for regulated industries. Native Workarounds: Storing vectors as JSON text in ODC Entities. I recently conducted a feasibility experiment to prove the "Native" path (storing vectors inside ODC to avoid external dependencies). You can see the architecture here: https://medium.com/@michael.de.guzman/proving-vector-storage-retrieval-inside-outsystems-developer-cloud-a89d8fb88661 The Problem: Currently, passing vector data between ODC and External Logic requires serializing arrays to JSON text. This introduces unnecessary overhead compared to passing native binary data. This creates a potential scalability bottleneck as dataset sizes grow. The Solution: Please introduce a Native Vector Data Type for ODC Entities and a built-in Vector_CosineSimilarity() server action (or Aggregate filter). The Benefit: This would allow ODC developers to build compliant, high-performance RAG and Agentic workflows entirely within the platform's trust boundary, without the massive overhead of JSON parsing.

In ODC it would be extremely valuable to have an official and supported way to perform direct queries against application databases in stages beyond Development. Currently, the only practical way to inspect database data is via ODC Studio in Development stage. Once the application is promoted to QA / Pre-Prod / Production, there is no official mechanism to query the database, even for simple troubleshooting or validation scenarios. This creates a real operational gap: In many cases, a simple SELECT query would immediately explain an issue. Instead, developers are forced to add temporary logging, deploy heavy diagnostic logic or reproduce issues back in Development (not always possible or effective). Adding logs purely for troubleshooting, increases noise in the code (lots of LogMessages) and often feels wrong when a safe DB query would solve the issue in minutes What would help: An official DB query tool for ODC Studio or ODC Portal feature for controlled data inspection with proper auditing, permissions, and safeguards. Why this is important: Modern cloud-native platforms rely heavily on observability and controlled introspection Troubleshooting issues in higher environments without DB visibility is unnecessarily hard This would significantly improve developer experience, support efficiency, and confidence in ODC Having an official, supported way to query stage databases in ODC would remove the need for workarounds and align ODC with real-world operational needs.

Today, when there is need to do some configuration in the destination environment of a deployment (site properties, timers, end points, etc), this configuration must be made after the deployment is done.Would be nice to have a way of preparing those configurations during the planning and see them being applied automatically during the deployment.

Forge is the lifeblood of OutSystems. All great platforms eventually realize the need for something like it: a mechanism that allows the ecosystem to grow beyond internal contributions alone. It is the mark of a mature system, and Forge is a genuinely impressive manifestation of that idea. The most critical component of any such system is giving credit where credit is due. Without a strong feedback loop between contributors and the value they receive in return, the whole thing starts to break down. Contributions are wholly dependent on that loop. If there is not enough incentive on one side of the equation, the system can no longer self-sustain. This is not a minor inconvenience; it threatens the health of the entire ecosystem. It thrives on symbiosis. To be honest, I am surprised (as a relative newcomer to OutSystems) that the system is as strong as it is. On first glance, the incentives are fairly weak. There is an inherent imbalance between the effort required to build and submit quality Forge contributions and what those contributors stand to gain. That the ecosystem works as well as it does reflects a community that has achieved something genuinely rare. I want to make that point concrete: somehow, the OutSystems community has accomplished what others in similar spaces could not. I would chalk it up to a large, motivated developer base that may sometimes be frustrated, but is ultimately a great collection of individuals focused on advancing the platform for their fellow developers. It is a real feat, and it deserves to be celebrated. But as they say, it is not all unicorns and rainbows. The ongoing challenge is sustaining what is already out of balance. Developer contributions are not adequately incentivized, and ODC has made this worse, not better. OutSystems contributions seem to be increasingly privatized. What may have once been public and GitHub-facing is no longer possible. In my (admittedly short) time as an OutSystems developer, working exclusively in ODC, my contributions are siloed. Traditionally, I would have a GitHub repo that speaks to my work, serves as a portfolio, and acts as the natural payoff for open-source and free-source contributions. That was the incentive. That was the feedback loop closing. With ODC, that loop is broken. My contributions are contained and constricted within the OutSystems ecosystem. No GitHub repo. Nothing I own or control. Everything is increasingly containerized in constructs that only exist within this platform. If I were a top contributor here, I would only be a top contributor here. My work no longer reflects what I am capable of as a developer broadly; it only reflects what I am capable of as an "OutSystems Developer." Those two things are not synonymous, and I think there are a lot of talented OutSystems developers who deserve to stand strongly as developers, full stop. I will give credit where credit is due: this approach is sticky for OutSystems, and the one-sided benefit is strong. Well done. But the problem is that the balance swings indefinitely toward the platform and increasingly so. I would argue this has always been the case, and ODC has only accelerated the trend. When the value of contribution flows almost entirely to the platform while the contributor's portable reputation shrinks, the symbiosis starts looking a lot more like extraction. While this may read like a rant, it is not. The whole point is shifting the balance a little more toward the developers who are giving their time, energy, and expertise to make this a better platform. This is about symbiosis: balancing the ecosystem so that the people who build it up are built up in return. The goal is to make the entire platform stronger by honestly acknowledging where it falls short. With that I'll leave my idea. Contributions from Forge or otherwise, should be something that a contributor can showcase to those outside the OutSystems ecosystem. If a contributor only reaps benefits from their contributions inside the OutSystems ecosystem and stands nothing to gain outside of it, it is not a favor to the developer and the main benefactor is clearly OutSystems. In time, I do not think that is beneficial for OutSystems and the broader platform.

I would really like to see some sort of "auto arrange" for Service Studio that just moves the items in an action to have nice even spacing, put the work for For loops to the side, make branches look nice, etc.J.Ja

Adding an option to send null values in JSON structures for objects and attributes is currently handled in the `onbeforerequest` event, and for very complex structures, this becomes very complicated. This would facilitate development.

Since "Wake Timer" can be called via code, it would be good to be able to pass paramters to it. J.Ja

I suggest excluding the static entities from the counting of Application Objects , as saving it leads to spaghetti code, and using it does not indicate the complexity or magnitude of the project.

Hi, this is just an idea for a developer's perspective, it would be nice to have the ODC workflow builder in ODC Studio itself instead of going back and forth from ODC studio to ODC Portal when developing for the workflow.