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

In Service studio, when we manage dependencies, we have an option to show only dependencies which are in use. However, in ODC studio, this option is not available. It will be great to have it there, as this is a very useful feature.

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.

Currently, the only way to share Outsystems code with LLMs or to show to a person on the forums, etc, is with a Screenshots, but a Screenshot cannot display everything at once: for example Input/Output parameters for several Actions in an Action flow in a single Screenshot. A single one side Service Studio -> Text Editor would open new doors, if you can Copy/Paste Service Studio elements in a text form to paste into LLMs or other text editors for AI code generations , context, creation of documentation, etc. It doesn't have to be perfect, it can be an imperfect, incomplete and invalid machine generated code (JSON, XML or any other text form, that is easier for the Service Studio team to implement), LLMs nowadays can quickly reformat it in a better form according to use case and extract whatever needed. It can help by virtually all of a module/application elements inside Service Studio, but among the most beneficial would be StaticEntities and Entities + attributes, Structures + attributes, Action in a flow (names + input/output parameters), etc.) in a text form. It is not the same as, but it would implicitly provide some solution for the problem from this idea: https://www.outsystems.com/ideas/11114/copy-multiple-property-names/