A ranking system for the Mentor Program where mentors earn points based on sessions they conduct. As their points increase, their ranking improves, helping us easily identify and connect with the most active mentors.

Under 'Exceptions' in ODC Studio/Service studio. Allow the creation of folders so User Exceptions can be grouped

 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.

It would be nice if OutSystems provides us with an instruction guide or video on how to implement an existing reactjs component in OutSystems reactive app or library module. There are many react UI components available for example to show data in a tree, that are not implemented in OutSystems UI. Using as guide on how to do this, the community can extend the usability of the reactive web development more easily.

Problem: Personal Environments cost OutSystems unnecessary AWS compute time, but deleting them frustrates developers who lose their apps unless they manually export them. Idea: Make Personal Environments ephemeral but with automatic daily app snapshots, so they can be safely deleted sooner without hurting the developer experience. How it works 1. Daily App Snapshots Automatically snapshot all apps/modules once per day. Store snapshots in cheap object storage. Only snapshot OML + metadata (default: no DB data). Developer never loses their apps again. 2. Faster Environment Recycling Only do this if needed to offbalance the data usage in point 1 Reduce always-on uptime from 7 days to 4 days. After 4 days of inactivity: Kill the AWS compute Keep the daily snapshots 3. Auto-Restore on Spin-Up When a user requests a new Personal Environment: OutSystems spins up new infra Automatically reinstalls the most recent snapshot Developer resumes instantly with their apps already there Benefits For OutSystems AWS savings (compute reduced from 7 to 4 days). Storage cost minimal vs. compute cost. Personal Environments become fully elastic. For Developers Apps are never lost. Personal Environment deletion becomes painless. Better trust, better onboarding, better learning experience.

Add something similar to "Export Action To Image" but with the actions objects numbered and a section below listing the parameters for each one . Also, a way to generate these in bulk , with it generating a zip file with them all inside, named appropriately, or as a PDF file.

Although there exist about 15 ideas on improving handling of unused references, non of them state the obvious: it could be done easily by OutSystems fully automatically! My proposal is that developers keep whatever references in DEV (or remove them if they want), but that on deploy to the next environment, OutSystems first automatically removes any unused references, before it starts the deployment. There is in my opinion NEVER a need for unused dependencies in the next environment where someone deploys an application to. As is is never needed, it can always automatically be removed.

While editing a LifeTime plan, I think it would be useful to have a counter that shows how many applications have been added to the plan . When the plan includes a lot of apps, and you know how many need to be deployed, it can sometimes be hard to tell if the numbers match. For example, let's say I have a plan with 25 apps, but I’ve only added 24. With a counter, I could quickly see that one app was missing from the plan. Right now I have to count the apps to see if I have all of them added. Cheers, João Heleno Mockup of a plan with the number of apps showing near the source environment title.

 Challenge: Currently, widgets in Service Studio don't have names by default. Developers typically only assign names when they need to manipulate widgets in business logic. However, widget names are essential for test automation because when a name is defined, the generated HTML element ID includes a static part (based on the widget name) alongside the dynamic part. This static portion can be used as a reliable selector in test scripts. Without named widgets, HTML element IDs are entirely dynamic, making test automation scripts fragile and prone to breaking whenever screen changes are made. This forces QA teams to constantly update test selectors. Proposed Solution: Auto-generate unique default names for widgets within each screen (e.g., Button1, Button2, Input1, Table1). This would: Provide stable HTML element IDs for test automation without requiring manual developer effort Make test scripts more robust and maintainable Reduce the time spent fixing broken tests after UI changes Improve overall application testability out-of-the-box Trade-offs: This would make the HTML slightly more verbose, but the impact would be minimal compared to the significant benefits for test automation and quality assurance workflows.

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