Many times, when developing an application, I have an action within a block that I need to trigger from the screen that uses it. I had many cases where this happens. For instance, let's say I have a button that will validate the the form within a block in the parent screen. I want to handle the validation just inside the block, and will need to perform the validations within it. Or when you want two blocks to react with eachother, but don't want to join them on a single block. Or even when I just want a button to perform an action that is inside the block. Currently, there are indeed some workarounds for it: Creating a dummy variable on the screen, that works as block parameter that will trigger the OnParametersChanged. This one gets complicated when you already have an OnParametersChanged set, but want to run just a single action; Handle all the data from the parent screen using events; Create an invisible button within the block, and set the onclick event to an external from the class or Id of the button - similar to this documentation page: https://success.outsystems.com/documentation/how_to_guides/front_end/how_to_call_a_block_action_in_a_mobile_screen/ But things get complicated when you have many blocks inside the screen, and this end with many "dummy" screen variables, too many screen actions just to perform an action that is already inside the block, or refactoring the screen/block to join them against your own will, and increasing development time. In blocks, the communication between the block and the consumer screen block are triggered by Events. It would be nice if we had the possibility to consume a screen action from the block, like setting it to "public" so you can run it from the parent. And would be way easier to manage this actions from blocks inside a list, so you would only need the row number to trigger the action. This issue brings many questions on the forum as well, like: https://www.outsystems.com/forums/discussion/73627/how-to-run-action-block-from-main-screen/ https://www.outsystems.com/forums/discussion/102238/triggering-save-action-from-block-using-a-button-on-screen-in-outsystems/ It would make the development cleaner, easier to follow good-practices and follow the low-code philosophy.

Working with multiple environments simultaneously is a standard practice, but Service Studio makes it hard to distinguish between them at a glance. Currently, a developer must check the status bar to know if they are in Dev, QA, or Prod. Introduce an "Environment Theme" feature where we can assign a specific color to each infrastructure. If I'm in Production, the Service Studio UI (or at least the tab bar) should have a distinct color (e.g., Red). Add the environment name as a prefix to the tab title (e.g., "[PROD] MyModule"). This would prevent accidental changes in the wrong environment and significantly improve the UX for developers managing complex lifecycles.

Currently, when using the Advanced SQL tool in OutSystems, developers are required to define an Output Structure even for SQL statements that do not return any data — such as INSERT, UPDATE, or DELETE queries. This mandatory output requirement introduces unnecessary steps in the development process. It creates confusion for beginners and adds extra overhead to simple operations that are not supposed to return results. Proposed Improvement: Introduce two different types of SQL tools to improve clarity and usability: ExecuteSQL_Select: for queries that return data (e.g., SELECT). ExecuteSQL_NonQuery: for queries that do not return data (e.g., INSERT, UPDATE, DELETE). ExecuteSQL_Scalar: for single-value queries (e.g., COUNT, MIN, MAX). These naming conventions are inspired by C# and other modern frameworks and would help improve developer efficiency and code readability. This change would eliminate the unnecessary requirement of defining output structures for non-query operations and streamline the development workflow.

If you try to use the Mod() (modulus operation, for taking the remainder) function in a Filter of an Aggregate, Service Studio gives an error:"'Mod' function cannot be executed in the database, so it can't receive any attributes from the aggregate as parameter."This is nonsense however, as Microsoft SQL Server has the corresponding "%" operator, and Oracle has a MOD() function, so both supported databases know how to perform a modulus operation just fine. Therefore, Mod() should be allowed in an aggregate.

This is a project aimed for Portugal, in a first phase, but which can be extended to other countries.It is just an idea and I count on the support of this forum to make it grow and solve the challenges! VisionEnable and manage the delivery of food and basic goods, in the form of a basket, to people who are more prone to be infected with coronavirus, already has coronavirus or is in quarantine. PersonasHypermarketsVolunteer to indicate beneficiaries and transport basket delivery Use casesRegistration of Hypermarkets- Responsible for creating the basketsRegistration of Volunteers- Responsible for collection and delivery to the beneficiaries respective addressesRegistration of beneficiaries- Registration will be done by the volunteer who indicates a family that meets the conditions to be a beneficiary Challenges- How to check if the family should be considered to benefit?- Definition of the basket. Should we have multiple types with different prices?- Online payments (only).- How to deliver safely? User Stories (draft)US1 - Registration of Volunteers- With facebook or google and with indication of the area of residence to define a range of action- Indication of the hours available to make deliveriesUS2 - Registration of Hypermarkets- As OutSystems has a close relationship with Continente hypermarkets, it would be easier to articulate with them in a first phaseUS3 - Registration of Beneficiaries- This registration must be done by the Volunteers through their account.- Indication of name, address, number of people in the householdUS4 - Task assignment to the Volunteer- At the end of each day, generate a route for the volunteer, which should be done the next day.US5 - Task completion- The beneficiary must indicate that he received the basket.I hope that this helps to understand the idea and that it can grow with the support of everyone.Thanks!

Currently in LifeTime, there is no easy way to identify which applications have bespoke (application-level) Content Security Policies configured. To check this, we must manually open each application and review its security settings in each environment. This becomes difficult to manage at scale, especially when CSPs are applied selectively across multiple applications and environments. It also introduces risk, as teams must rely on memory or manual tracking to know where custom CSPs have been configured. It would be highly beneficial to have: - A way to filter or list applications with custom CSPs in LifeTime Visibility per environment to understand where overrides exist - A clear indication of whether an application is using environment-level CSP vs application-level CSP This would significantly improve security governance, reduce manual effort, and help teams maintain consistent and auditable CSP configurations across their platform.

To monitor errors in Service Center, having the kind of exceptions that have been raised could be very helpful. The exceptions are already on the error log but not their Type, for example, "Database Exception", "Security Exception" and for User Exceptions, it would be very helpful. Should have filters / categorized.

Most of the times server actions, client actions can have multiple branches. While debugging each node is currently available it would save a lot of time if we could just hit continue and the app automatically highlights the full path the execution has traversed. The Idea is to have like a highlighted flow in the server actions, client actions, data actions etc. where developers can see exactly which flow the execution is going wrong in and make fixes accordingly. This would help debug faster, saving the time to actually understand what each node is doing and also understanding the logic on a broader level.

Hello, community! 👋 Having worked with OutSystems over the past few years—surviving the nightmares of broken references and monolithic architectures in O11, and now exploring the isolation of microservices and the AI Agent Workbench in ODC—I started reflecting on the next evolutionary leap for our platform. OutSystems Mentor already helps us generate screens and initial logic from prompts, which is fantastic. But what about large-scale maintenance and refactoring? Our beloved TrueChange is brilliant at pointing out where the application broke. If I change the signature of a core Server Action (e.g., changing an Input from Text to a Record/Structure) or delete an attribute from an Entity, TrueChange turns everything red in the Consumers. But I still have to go into 20 different modules and fix the mapping manually. The missing feature today: TrueChange Auto-Healing (AI Semantic Refactoring) What if ODC integrated an AI engine directly into TrueChange that didn't just point out the error, but wrote the fix automatically for your review? How it would work in practice: The Trigger: You change the return of an API or the structure of an Entity in your Producer module. The Analysis: The AI Auto-Healing engine detects that 15 Consumer apps broke. Instead of just throwing errors, the AI analyzes the semantics of your change. The Action: The engine scans the Server Actions and Data Actions of the consumers and rewrites the mapping logic (adding Assigns, converting data types based on context, or modifying Aggregates). The Code Review: In ODC Studio, you get a "Pull Request" style notification. You see a visual diff (before/after) of the logic altered by the AI across all consumers, and you just click "Accept All" or reject and adjust it manually. This would transform the platform from "Low-Code" to "Zero-Maintenance Code" at the architecture layer.

In Reactive Web applications, it is common to have multiple front-end modules within the same application. Currently, Client Variables are scoped to a single module, which creates challenges when we need to share session-like data across modules. A common workaround is to centralize these variables in one module (_CW) and expose them through public client actions. While this approach works, it introduces some limitations: It increases complexity It requires additional control over events to retrieve the variable It cannot be used in Aggregates or Data Actions, since client actions are not supported in those contexts, even though module-level client variables are My suggestion is to introduce the ability to mark Client Variables as "Public", allowing them to be accessed across modules via references, similar to how public elements (e.g., actions, structures) are exposed today. This would enable: Direct access to shared client state across modules Cleaner and more maintainable reuse Elimination of unnecessary client actions and events used to retrieve values Consistent usage of client variables in UI logic and data-fetching layers This improvement would simplify cross-module state management and reduce the need for workarounds, especially in larger applications with multiple front-end modules.