It is great that the OutSystems demo Homebanking apps are multilingual and also available in German. Nevertheless it is obvious the translation was not done by a German native speaker. In this way it is - to be honest - a little bit funny, instead of being a serious business app. E. g. the credit card VISA was translated as Visum in German language, which only means a visa for a country, not the credit card. And a lot of other stuff. English name -> curent translation - suggested translation Visa -> Visum -> Visa (I think it the same for the Portuguese word here: Visto) Home -> Heim -> Startseite Balance -> Gleichgewicht -> Kontostand Amount -> Menge -> Betrag Continue -> Weitermachen -> Weiter Loans -> Loans -> Kredite View -> Sicht -> Überblick Share Receipt -> Aktienquittung -> Quittung It would be great if these Homebanking apps (maybe others also) could be checked by a native German speaking OutSystems employee of the DACH-region.

In ODC we should be able to open external logic files downloaded from Forge to check the code inside. Without knowing what is being done, we are just trusting in the actions comments without knowing exactly the logic inside and leading to possible privacy and security risks. O11 Integration Studio was more transparent on this. It was also more simpler and quick to create extensions.

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:

Would be a (minor) quality of life feature if you could bind a label to an input if you simply drag and drop it from the tool box on the left straight on the Input widget. For example here, this widget is bound to a "Max records" local variable, to control how many records an aggregate returns. If I drag the label on to it, it could do several things: Add the label on top of the Input Set the Input Widget automatically on the Label properties, and give it a name like "InputName_Label" Set the text for the label on a 'best guess' case, depending on what the input is bound to (for example here, Max records) This could work for all other input type widgets: text area, switches, checkboxes, dropdowns, etc.

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.

First off, the "Create Action Wrappers" feature is really useful. When you right-click an Entity and generate the Create and CreateOrUpdate server actions, the platform already checks for Mandatory attributes. If a developer misses assigning a value to a mandatory field, an exception is thrown at the application level. That's a nice touch and saves a lot of headaches. One thing I noticed though is that for Text attributes, there is no validation on the defined Length. So if a developer passes a string that is longer than the max length set on the attribute, the value still goes through to the database and you get the classic "String or binary data would be truncated" error. That's a database level error, not an application level one, and it gives the developer zero context on which attribute caused the problem. Since the platform already knows the Length property of each Text attribute (in the Entity definition), it would be great if the generated wrapper could also validate against it. Same pattern as the Mandatory check, just extending it to include a Length check for Text attributes and throw a meaningful exception before it hits the database. This could help by: Making the generated wrappers more complete and consistent Giving developers clearer error messages during development and runtime Reducing unnecessary database round trips for data that was never going to be accepted anyway Really appreciate how the platform already handles the Mandatory side of things. This would just be a nice extension of that same thinking. Would be great to have this for both O11 and ODC. Thanks for considering!

Currently in OutSystems Reactive , there is no native, straightforward way to render dynamic HTML content inside an Email Template. Expressions Escape Everything : The standard Expression widget in the Email editor automatically escapes all HTML tags, converting them to plain text. Missing Property : Unlike standard Reactive Web screens, the "Escape Content = No" property is missing from Expressions in the Email editor. No JavaScript Support : Emails are rendered server-side, so common web workarounds like using a JavaScript OnReady action to set innerHTML do not work in an email context. Container Limitations : Using a Container with an innerHTML attribute often results in empty content because the platform's internal email engine (similar to an internal GetEmailHtml method) frequently strips these attributes during generation for security reasons. OutSystems should implement one of the following to improve the developer experience: Enable " Escape Content = No": Add the same property found in standard web expressions to the Email Expression widget, allowing developers to pass sanitized HTML directly. Native HTML Widget for Emails : Enable the "HTML Element" widget within the Email UI Flow toolbox so developers can explicitly define HTML tags and inject attributes safely. Sanitized HTML Input : Provide a dedicated widget or property that specifically accepts the output of the SanitizeHtml action and renders it as formatted HTML in the final email body. Thanks, Ananth

Enable to Test an Action giving new input parameters.

Hi everyone, I would like to propose the creation of an official training path and a specialization certification focused on Digital Accessibility, covering both OutSystems 11 and OutSystems Developer Cloud (ODC). As Low-Code developers, we have the responsibility to ensure that applications are inclusive by deeply applying WCAG standards within Service Studio and ODC Studio. My suggestion is for OutSystems to offer: Accessibility Guided Path: A comprehensive training focused on using OutSystems UI accessibly, handling ARIA roles, managing focus, keyboard navigation, and testing with screen readers. Specialization Exam: A technical validation for developers who have mastered the implementation of accessible interfaces in Reactive and ODC applications. Profile Badge: An official badge on the community profile, allowing partners and clients to easily identify developers capable of delivering high-quality, inclusive projects. Why is this important? Market Differentiation: Accessibility-certified professionals are rare and highly valued by large enterprises. Product Quality: It reduces technical debt and ensures that "High Performance Low-Code" also means "High Inclusion." Platform Strength: It demonstrates that OutSystems leads the market not only in speed but also in social and technical responsibility. I believe an "Accessibility Specialist" badge would elevate the technical level of our community and help build a digital world for everyone. #Accessibility #Certification

Full widespread support for null values, in all layers: database, actions, ...Not fake zeros disguised as nulls, but real thing, the ones that we can compare to is null. The ones that mean "I don't know the value for this... I don't even know if its zero"