In each training video on the OutSystems learning platform, include a “Schedule Call with Mentor” button (as shown in the attached image). When clicked, it can redirect learners to the ADP mentor list, allowing them to easily schedule a mentorship session. For freshers, this feature would be extremely helpful to learn faster, clarify doubts instantly, and gain confidence in their learning journey. Currently, many newcomers know about the forum, but not about the mentorship program. By placing this button directly within the training page, it encourages them to explore and connect with mentors proactively.

In ODC it would be extremely valuable to have an official and supported way to perform direct queries against application databases in stages beyond Development. Currently, the only practical way to inspect database data is via ODC Studio in Development stage. Once the application is promoted to QA / Pre-Prod / Production, there is no official mechanism to query the database, even for simple troubleshooting or validation scenarios. This creates a real operational gap: In many cases, a simple SELECT query would immediately explain an issue. Instead, developers are forced to add temporary logging, deploy heavy diagnostic logic or reproduce issues back in Development (not always possible or effective). Adding logs purely for troubleshooting, increases noise in the code (lots of LogMessages) and often feels wrong when a safe DB query would solve the issue in minutes What would help: An official DB query tool for ODC Studio or ODC Portal feature for controlled data inspection with proper auditing, permissions, and safeguards. Why this is important: Modern cloud-native platforms rely heavily on observability and controlled introspection Troubleshooting issues in higher environments without DB visibility is unnecessarily hard This would significantly improve developer experience, support efficiency, and confidence in ODC Having an official, supported way to query stage databases in ODC would remove the need for workarounds and align ODC with real-world operational needs.

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.

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

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.

An app where developers can create AI Agents using Mentor inside ODC, guided, structured, and production-ready. A lightweight app that helps developers: Define an Agent purpose Generate the System Prompt Suggest Actions Recommend Grounding strategy Propose Memory configuration All using AI guidance with Mentor.

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.

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

ODC Portal should have a screen with a interface to manage all the setting of the OuSystems Cloud connector, instead of a command line.

 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.