I would like to have a sort of a screen in the Service Center where all this information would be centralized and displayed, and where it would be possible to list all APIs and to navigate to the API edit screen from there.It is not the first time where I am in a project where it is used a middleware for APIs management inside the organization. And a problem that always happens when, for some reason, the middleware changes its DNS, so from xyz.whatever to azurexyz.whatever, is that to make the changes in all the currently used APIs I need to go espace by espace (or module by module) in Service Center, assuming that I don't need to go into SS to see where all APIs are located and I don't miss any of them and change one by one.I know it is possible to have this kind of list looking into the system entities, but I believe this should be part of the product because it seems to be commonly necessary.This would also help, in cases like the example, I described above, to make sure that we don't forget any API where the URL basis needed to be changed.

I would like to be able to add comments to True Change warnings when I hide them, so the other developers on the team know why I hid them. For example, if I make a mandatory field non-mandatory, and hide the warning, I want them to know what my reason is so they do not just change that setting. We have had a number of problems in the past because someone followed True Change warnings when they should not have. :( J.Ja

Currently, the Serialize node only provide an option to exclude attributes that have default values. However, there is no option to explicitly exclude custom-selected attributes. This capability is especially useful for logging scenarios . In many cases, creating an additional Structure just to map and exclude specific attributes is redundant and unnecessary. Most serialized outputs are eventually passed to a JavaScript node , written to logs, or stored in a database purely for logging purposes. Allowing developers to select which attributes should be excluded during serialization would significantly reduce development time, keep the code cleaner, and improve maintainability. It would also eliminate the need for extra mapping structures that add complexity without real value.

It is difficult to track down a version of a forge component once you have installed it in your environment and the component receives new updates from the community.It should be easier to check how far behind I am in adopting a newer version of a particular forge component by just going to Service Center or best in LifeTime itself.Based on a trustable hashing algorigthm, why can OutSystems not determine if the package hash for the version of Forge component is matching with a signature with a published component and if so flag it to me easily. If the match does not happen then tell me that I have customized the copy of forge component so it is not possible to track it against the public repository.

Enable the use of blocks in reactive emails. Currently all that is able to configure inside reactive emails is shown below. It would however be very helpfull if we could use also use blocks

Current CSPs rely on allow-listing domains which is difficult to secure, and vulnerable to attackers bypassing the CSP. As an example, it is currently impossible to implement Google Tag Manager without compromising an Outsystems Content Security Policy, as it requires both the unsafe-inline directive. It also requires allow-listing the www.googletabmanager.com domain which is found to host JSONP endpoints, which also can be used to bypass the CSP. See: https://csp-evaluator.withgoogle.com/ for a report The recommended approach is to use server generated nonce tokens in the CSP, and also in the scripts that are allowed to load. These scripts are considered trusted and may in-turn safely load script from other, cross domain sources. For tag manager, a recommended setup is here https://developers.google.com/tag-platform/security/guides/csp My suggestion is for Outsystems to support generation of nonces in the CSP headers returned to the client, and allow the front end to load a developer defined script with the same nonce tag. From there we could load any other cross domain resources without needing to weaken the CSP. For more information, see https://web.dev/articles/strict-csp

OutSystems now supports storing settings as secrets in both OutSystems 11 (Site Properties as Secrets) and OutSystems ODC. However, secrets often have an expiration date, and without proper tracking, they can expire unnoticed, causing disruptions. Proposed ideas : Optional Expiration Date for Secrets – Allow users to set an expiration date for secrets stored in Site Properties (OutSystems 11) and Secrets (OutSystems ODC). Reminder Notifications – Enable reminders to be sent before expiration to a specified role so they can take action. This feature would help OutSystems 11 / ODC users proactively manage secrets and avoid unexpected failures due to expired credentials.

In Client Web applications, when performing custom validation on a Form, developers cannot directly set Form.Valid manually. This creates a limitation in advanced scenarios where validation conditions can't be fully handled by the built-in validation framework. For example, if a developer wants to invalidate the form based on a business rule such as: Number < 100000 there’s no way to directly set: Form.Valid = False Instead, developers are forced to: Create an extra local boolean variable to store the validation result Reuse the same condition again when checking whether to proceed or show an error This results in code duplication, reduced maintainability, and extra steps for logic that should be simple. A better approach would be: Allow manual control of Form.Valid — enable developers to set it to True or False inside client logic flows or expressions Or introduce a built-in method like Form.Invalidate() that can be triggered conditionally, without relying solely on form input widgets This would: Simplify complex validation scenarios Reduce the need for extra variables and duplicated conditions Improve logic readability and maintainability Let developers manage validation state more directly

It would be great if I could expand an assignment to some structure like is already possible for parameters of an action.

When creating an entity diagram, have the ability to hide the attributes. This would make it easy to see the relation between entities easily.