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.

Just like "Action's" folder allow user to add folders to the Entity and Structure tree.

Hi, I am new and I am being currently trained for the new ODC studio. While working with the ODC Data Grid and more so with the dropdown Column I notice something and asked the ODC AI and looked in documentation and found this... Build a list of dropdown options for a Data Grid DropdownColumn (type DropdownOption2.List). Populate it in the Aggregate’s On After Fetch client action. Include a synthetic first option like “Select genre” (so users can leave the value empty), then add one option per record returned by GetGenres. Normally the flow looks like: Start with an empty list (TmpOptions) Create a DropdownOption2 record for “Select genre” Append/Add it to TmpOptions Loop genres, create DropdownOption2 for each, append/add Assign GenreOptions = TmpOptions Bind DropdownOptionList = GenreOptions Why you couldn’t finish it: In your ODC environment, the client action toolbox did not expose any list-manipulation nodes/functions (like ListAppend/Add/Insert/Clear). Without an “append/add” capability, you can’t programmatically build a DropdownOption2.List row-by-row in that action. That specifically blocks the “prepend a default option” pattern, because you have no way to insert one extra item ahead of the real data. What that means in practice: You can still bind the dropdown to a list that already exists (for example, an aggregate result mapped into dropdown options, if the component supports that mapping). But you cannot “manufacture” a new list with an extra first item inside the action unless list add/append is available. So I think it would be helpful to bring that tool and probably many others to the over to ODC to improve the work flow to match what was able to be done it seems in OS11 and if not then this should be created so that I can be done in a no code way. Thanks Tim

In the new Service Studio alert that shows the forge components that have new updates, there could be an "update all" option or checkboxes and and an "update selected" option.

Create a system action in ODC where a message can be logged to the error log. LogMessage will log a message to the general log. O11 has the AsynchronousLogging extension that has a LogError action, but ODC does not. In ODC, an application can log to the error log by throwing an exception. However, there are occasions when the application needs to continue processing. In this scenario it would be useful to log a message to the error log and continue operation.

Greetings, Service Studio comments are used for notes, reviews & reminders. Most of the time the reminders act as an backlog to be resolve by someone in the team accountable. Currently there's no built-in way to highlight the accountability/ownership for a reminder [ except what we mention as a text] Having an feature of @mention-user-name where the studio to populate/autoSuggest the env IT Users/Developers would create a reference for the respective user so that while they access the module in studio its more easy for them to trace there accountable reminders. example : @abc.xyz please validate this aggregate filter - Auto Suggest when type@ - Would ne awesome if the mentioned user receive some sort of notificaton🔔 in studio itself 🙂 - More advance ahead; notification should navigate or open respective module & show the reminder action/respective stuff [ sync tree] Thank you for considering this enhancement in advance Assif

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

We work on projects we don't always have time to work on our own stuff and what does OutSystems do? You punish us for working hard and promoting YOUR product by deleting our personal environments. STOP IT. Why don't you figure out a way to determine if we are high-end enterprise users? If we are LEAVE our personal environments alone.

Whenever you create a new object in service studio, please put the focus immediately on the name property of this object, so you can start typing the name without having to select it explicitely. You never need a nameless object, so you always have to make this extra click, which is really annoying. This applies to (but not only to) new actions, parameters and variables. On top of that, this feature is already there for roles, entities and site properties for example, so please make it consistent for everything.

 The Problem Currently, the "Create Entity Actions Wrappers" (CRUD actions) feature in Service Studio follows a static, hard-coded template. While this is helpful for rapid prototyping, most professional enterprise projects require specific architectural patterns that the default scaffolding doesn’t support. As a result, developers must manually wrap every generated action to include: Audit Trails: Automatically filling CreatedBy or ChangedAt attributes. Standardized Exception Handling: Ensuring specific UI or Log messages are triggered. Validation Logic: Checking for business rules before execution. Naming Conventions: Adhering to specific project-wide naming standards for wrappers. This leads to a significant amount of repetitive, manual work every time a new entity is created, increasing the risk of human error and architectural inconsistency across the team. The Proposal The introduction of a Custom CRUD Pattern configuration within Service Studio (at the Application or Environment level). This feature would allow architects to define a "Blueprint" or "Template" for CRUD generation. When a developer right-clicks an entity and selects the option to generate actions, Service Studio would check for a defined custom pattern. If found, it would generate the actions based on that template instead of the default OutSystems standard. Key Capabilities: T emplate Definition : Define a standard flow for Create, Update, and Delete actions. For Validation actions as well, for example would automatically check if the mandatory attributes are not empty. Placeholder Support : Use variables for Entity names or attributes within the template. Boilerplate Logic : Automatically include logic like "GetUserId()" or "LogRecord" in every generated action. Architecture Alignment : Ensure all entities immediately follow the project's "Good Practices" without manual intervention. The Goal The goal is to move from "Standard Scaffolding" to "Architectural Scaffolding." This would significantly speed up the development of new entities, ensure the entire team follows the same patterns from day one, and reduce the technical debt caused by inconsistently wrapped CRUD Actions. Ultimately, both options would exist simultaneously. The idea is not to replace, but simply to add a new option.