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

The idea of one general unit of measure to rule them all does not work well for a cloud based SAAS platform. Note, this idea is specifically focused on ODC. Looking at one of the most popular ideas submitted https://www.outsystems.com/ideas/14656/charging-1-ao-for-static-entity-is-not-worth-it/ it's clearly evident that using AOs as a measurement does not align with customer expectations. Static entities are one great example but it doesn't end there. The frustration with this pricing model likely stems from 2 things: The service/convenience (remembering the basis is SAAS) is not worth the actual cost (AO) The service cost does not make sense given the infrastructure/software required for OutSystems to provide it. e.g. what it costs OutSystems to provide this is significantly less than what they are charging customers (large margins). With that out of the way, the actual idea would be to abandon the AO cost model and adopt one that is more granular and tied closer with what we see from the SAAS cloud provider market. As an example, if I want to expose a REST API on AWS, I don't pay per endpoint because that makes no sense. Could AWS charge that way? Sure. The reason they don't and the same reason other cloud providers don't is because it doesn't scale because an endpoint infrastructure cost. To list things that don't seem to scale with AO pricing: AO per screen Static Entities Entities Charging per API method whether its creation vs consumption Custom defined events I get that the AO unit of measure is simple and changing it means buying in to more complexity from the OutSystems perspective. The overarching need to buy in to the complexity though IMO is that it steers customers away from using the platform as intended and as a result pushes that complexity burden down to the customers. That seems to be very contrary to the mantra of what OutSystems represents with being a low code platform. I feel its important to state that this has nothing to do with OutSystems right to make a profit or what that profit is. It should wholly be expected that OutSystems has a profitable margin on any service they offer as long as customers are willing to pay for it. The goal is simply to: Encourage customers to adopt OutSystems services broadly by avoiding prohibitive pricing structures Increase pricing transparency and as a result improving the ability to forecast/budget scaling cost Adopt a pricing model that customers can more easily reason about

 Use-case: I have an app with many screens and tons of CSS classes defined in the style sheet; I decide I no longer need one or more screens, so I delete it/them; now, I have a bunch of CSS classes defined in the style sheet that are no longer used anywhere in the app. Problem: I don't want unused CCS classes in the style sheet, so now I'm forced to search for each class in the app to check if it's used or not before safely deleting its definition. Solution: there should be an easy way to "Removed All Unused CSS Definitions", just like there's a "Remove unused elements" (see image), and/or a visual cue on the Style Sheet, next to each unused CSS definition, to make it easy for thee developer to see that that particular definition is not being used (that way the developer can manually delete only the ones they're sure they'll never use again).

 Current Context In the current version of Service Studio, all Local Variables share the same icon (a yellow square), regardless of their data type. The only visual indicator that a variable is a List is the small expansion arrow on the left or the naming convention chosen by the developer. This uniformity makes it difficult to instantly distinguish between a single record/primitive type and a collection of data. The Proposal I propose the introduction of a specific icon or visual badge for List-type variables. Instead of the standard square, a "stack" or "layers" icon should be used. This would allow developers to immediately identify that they are dealing with a collection, rather than a simple Text, Integer, Boolean, or Single Structure variable. Why is this important? Reduced Cognitive Load: Developers would no longer need to hover over or click a variable to confirm if it is a single record or a list. Identification becomes instantaneous. Error Prevention: It makes data mapping to widgets (such as Tables or Lists) and the use of "For Each" loops much more intuitive, preventing type mismatch confusion. Improved Code Legibility: Complex actions with numerous variables become significantly easier to scan visually, enhancing development speed and overall Developer Experience (DX). Suggested Visual Changes Simple Variables: Maintain the standard yellow square icon. List Variables: Use a "List" symbol (e.g., three stacked lines ≡) or add a small "stack/layers" badge overlaid on the existing icon.

Because sometimes you already know your timer execution has gone bad and you just want to stop it.

Hi everyone,I spend a lot of time inactivating the users who should not have access to an environment for some reason. What I would like to suggest is for us to have the ability to set an expiration date for each user that is not an administrator.This way I can easily manage the users on my factory especially when we have outsourced developers.

Currently, OutSystems only allows limiting the total number of simultaneous process executions across the environment. There is no way to restrict concurrency per process type, which can cause problems when a single process spawns many instances. For example, starting 1000 BPT processes of the same type can consume all available execution slots, effectively blocking other processes from running. A per-process concurrency limit would allow developers to define a maximum number of simultaneous executions for each process (e.g., 4 instances at a time). Additional instances would automatically be queued until a slot becomes available. This feature would provide: Better control over resource usage for high-volume processes. Reduced risk of process starvation, where other processes cannot execute because one process is using all slots. Simpler queue management without custom throttling logic. Introducing per-process execution limits would make process orchestration more predictable and efficient, allowing developers to safely run multiple processes in parallel without one process dominating the system.

When working on the theme I accidentally introduced an error by putting a square bracket in one of the lines, like the one we can see in line 92 here: This did not raise any errors on TrueChange allowing me to publish the theme and break all the classes that were below that line. Since the theme was visible in the sources of the browser and properly loaded, it took too much time to realize it was a simple syntax error. This could have been avoided if TrueChange would not allow to publish CSS with syntax errors.

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

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.