So the openapi specification that is found in the documentation of the ODC Rest APIs has the openapi version set to 3.0.4. However, if you feed it as input to consume in ODC Studio, only versions up to 3.0.3 are supported. Anything higher is (currently) just refused. it returns the very meaningful message that the format is not recognized. (for which i'll make another idea) So why not keep these 2 in line, and only put versions in the documentation when they are also supported in ODC Studio?

I have two instances of Service Studio open, each connected to a different environment. When I do a 'Find Usages' on an element from Module A that is used in Module B (where Module B is only open in the other instance/environment), it points me to that other instance and it doesn't bring that Service Studio instance into focus. My idea is that Service Studio should open the module in the current instance instead, especially when the environments are different.

Currently in LifeTime, there is no easy way to identify which applications have bespoke (application-level) Content Security Policies configured. To check this, we must manually open each application and review its security settings in each environment. This becomes difficult to manage at scale, especially when CSPs are applied selectively across multiple applications and environments. It also introduces risk, as teams must rely on memory or manual tracking to know where custom CSPs have been configured. It would be highly beneficial to have: - A way to filter or list applications with custom CSPs in LifeTime Visibility per environment to understand where overrides exist - A clear indication of whether an application is using environment-level CSP vs application-level CSP This would significantly improve security governance, reduce manual effort, and help teams maintain consistent and auditable CSP configurations across their platform.

Currently, when a developer enables a breakpoint in a shared environment (like Dev or Test), all active sessions hit that breakpoint. This disrupts other developers and interrupts their work. Introduce a "Debug My Session Only" toggle within Service Studio. When enabled, breakpoints would only trigger if the request originates from the developer’s own authenticated user session or specific IP address.

To add a link or a way to quickly open the Event Handler Action from Properties / Events of UI Widget. This can be extended to On After Fetch of Fetch Data From Server or UI Aggregrate. This will improve the developer experience to quickly open the Client/ Screen Action that assigned as Event Handler or After Fetch Event rather than scroll up and down Elements Tree For Button and link, we can quickly double click the Element in the canvas to quickly access the OnClick Event Handler already, however, this should be good if there's a similar way for other Widget like Dropdown, Switch, Custom WebBlock with Events, Data Fetch Aggregate...

When compiling or publishing an application, it would be helpful if errors and warnings could be grouped by Screen, Block, or Action.

Although there exist about 15 ideas on improving handling of unused references, non of them state the obvious: it could be done easily by OutSystems fully automatically! My proposal is that developers keep whatever references in DEV (or remove them if they want), but that on deploy to the next environment, OutSystems first automatically removes any unused references, before it starts the deployment. There is in my opinion NEVER a need for unused dependencies in the next environment where someone deploys an application to. As is is never needed, it can always automatically be removed.

There are plenty of scenarios in which the base built-in actions are not enough. For example, if creation of a specific entity record demands that other entity records be also created, or if certain restrictions apply that cannot be modeled with static "default values". Or simply because you want to audit operations over sensitive entities. Currently the way to do this with the Agile Platform is clumsy: isolate entities in their own eSpace, make them available read-only, and create sets of actions to do the required tasks. This works, but: It is ugly - when actually using those actions, you will not see them associated with entities; you need to remember that they need to be imported, look for them under "referenced actions", remember from which eSpace they come from - or go look in the entity list; It can lead to errors - if a new developer in a project using the pattern, for some reason, is not properly informed, he might simply go into the eSpace and switch the read-only property off, anticipating that it being that way was an error.

Currently, the OutSystems UI stylesheet applies a box-shadow effect through :focus when accessibility features are enabled. As a result, the focus indicator is shown both for keyboard navigation and mouse interaction. It would be preferable to use :focus-visible instead, so the focus indicator is only displayed when it is relevant, namely when users are navigating with the keyboard or using assistive technologies. This would provide a more appropriate default behaviour, improving the experience for mouse users while preserving a clear and accessible focus state for keyboard navigation.

While editing a LifeTime plan, I think it would be useful to have a counter that shows how many applications have been added to the plan . When the plan includes a lot of apps, and you know how many need to be deployed, it can sometimes be hard to tell if the numbers match. For example, let's say I have a plan with 25 apps, but I’ve only added 24. With a counter, I could quickly see that one app was missing from the plan. Right now I have to count the apps to see if I have all of them added. Cheers, João Heleno Mockup of a plan with the number of apps showing near the source environment title.