As OutSystems is moving away from providing licenses with unlimited ao's could we get the ao count for forge items listed in the forge?

Branching could be useful in different situations, some more relevant than others, but on big factories with a team with several developers, it could be very useful.A situation that occurs frequently is when we receive a change request which requires changes on core entities, this will break the environment , and will affect other developers that are working on a different feature, but are prevented of testing/developing without pain since the environment is broken.So it would be great of having an way of creating a branching per pta of a solution, were the developer could make the change that will break the environment isolated, finishes the development, could test it isolated again (remeber that i've mentioned a branch of the solution), if everything is ok, perform the merge of the branches, create a new solution and schedule the publish.Im mentioning PTA was a way of doing it, it could be by branch, if it was possible to work on different espaces on a context of a branchIf i was a smoker i would quit smoking with this feature :)

OutSystems certifications are highly valued by developers and organizations worldwide. However, unlike many other global certification programs (e.g., AWS, Microsoft, IBM), OutSystems currently does not issue Open Badges for its certifications. Open Badges are digital credentials that embed metadata into badge images, making them verifiable, shareable, and portable across platforms. They are standardized by the 1EdTech Consortium (formerly IMS Global Learning Consortium) and widely adopted in education and industry. https://www.imsglobal.org/spec/ob/v3p0/ By enabling Open Badge support for OutSystems certifications, the platform can: Increase visibility and recognition of certified professionals Improve integration with digital portfolios and LinkedIn profiles Align with international standards for credentialing Enhance motivation and engagement among learners Implementation can be streamlined using existing platforms like Credly, which many organizations already use for badge issuance. The cost and operational burden are moderate, and the benefits in branding, community engagement, and learner experience are significant. We hope OutSystems will consider adopting Open Badges for its certification programs to further empower its developer community and strengthen its global presence.

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

 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.

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.

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.

 The BaseTheme used in Outsystems, as like most of the designers in the market, use the   multiple of 8  rule to create sizes for margins, padding, font sizes, grids... So, if BaseTheme uses the same rule for variables for everything why not use it in the Style Tab too?   Benefits : Less maintenance , Easier for the Develop team to match mockups margins and paddings. Less frustration,  Help experience between the Develop team and the Ui/Ux/ FrontEnd teams easy and softly. Less work for the FrontEnd team finding wrong margins and paddings. Apply best practices , (One-click change everywhere) , Even if there is inline CSS (which isn’t the best practice) when the variable is changed on the theme, the value is automatically updated everywhere. CSS learning ,  Make the Develop team more familiar with the CSS variables.