It would be (very) nice to be able to copy/past, at least actions and structures, from one extension to another.

Scheduled deployment is a smarter, more efficient alternative to manually clicking the deploy button. By automating and scheduling deployments, organizations can improve consistency, reduce errors, and optimize resource usage. Adopting scheduled deployment as part of a robust CI/CD pipeline ensures smoother, more reliable software releases, ultimately leading to better operational efficiency and user experience. Benefits of Scheduled Deployment 1. Reduces Human Error Manual deployments rely on human intervention, increasing the risk of mistakes, such as deploying the wrong version or skipping a critical step. Scheduled deployment eliminates this risk by automating the process. 2. Ensures Consistency and Reliability With manual deployment, inconsistencies can arise due to variations in execution. Scheduled deployments follow the same automated process every time, ensuring reliability across different releases. 3. Optimized for Off-Peak Hours By scheduling deployments during low-traffic periods (e.g., midnight or early morning), teams can minimize disruptions to users and reduce the risk of downtime. 4. Frees Up Developer and Operations Teams Developers and DevOps engineers no longer need to be present at odd hours to manually deploy updates. Instead, they can focus on more critical tasks while the deployment occurs automatically. 5. Enables Continuous Deployment (CD) Scheduled deployment is a key component of Continuous Deployment (CD), allowing teams to release updates frequently without manual intervention. This results in faster iteration cycles and quicker time-to-market for new features. 6. Supports Rollback and Disaster Recovery With automated deployment, rollback strategies can be implemented to quickly revert changes in case of failure. This ensures better disaster recovery and system stability.

Currently, OutSystems Service Studio does not support changing: The editor font family and font size in the Service Studio interface (Toolbox, Widget Tree, Properties panel, etc.) The overall UI scaling for high-resolution displays The language of the Service Studio interface (menus, property labels, and tooltips remain in English) While we can fully style our application UI, we cannot customize how the Service Studio development environment itself looks or behaves in terms of text visibility and localization. Most leading IDEs (like VS Code, Eclipse, IntelliJ, Android Studio) support: Font and UI customization Localization of interface into various languages By enabling these in Service Studio, OutSystems becomes more developer-friendly, more inclusive and better suited for international markets It would create more impact like Increased developer productivity and satisfaction Compliance with accessibility standards Easier onboarding of non-English speaking teams

Css makes wonderfull things but its not easy to work with when we whant to change something, changing a litle color can make us whant to kill someone, by integranting sass-lang on service studio we can get more power managing our css. check out more info on https://sass-lang.com/

 An italian hospital ran out of valves and a company 3d printed the valves: https://www.3dprintingmedia.network/covid-19-3d-printed-valve-for-reanimation-device/My proposal is an app to crowd-source this kind of effort:- Administrators are responsible for registering and validating the registration of legitimate entities with legitimate needs- Entities make requests- The public provides solutionsThis can be implemented by a small team in a very short time and can help save lives.Most people want to help and don't know how, let's give people that chance to contribute.

 Current Situation When configuring multiple modules, the system performs individual Catalog updates for each module, which increases execution time when the number of modules is large. Problem Statement When the number of items increases, users are required to: Select and configure each item individually . Proposed Enhancement Introduce a “Select All” option that enables: Selecting all relevant items at once Executing a single batch update on the Catalog instead of multiple individual updates

It would be great to have a visual feedback when we have dependencies to update or even when they are outdated and need some action to validate and update them.A preview of what could be to help us.This could be validated when opening the module (as it is already being done) but it would give a visual feedback even when we don't have breaking dependencies. It could also be checked after publishing for example.As this would only validate the used dependencies, probably wouldn't take as much time/effort like when we open the popup itself.

I think "For Each" elements should behave the same as "If" elements in regard to its label.When the Label parameter is blank, its Record List should be shown instead.Here's what a For Each with no label currently looks like. Caveat: when reading through the code, I have no clue which list the For Each is iterating until I click it.Here's what it should look like in this example above. Much better:  I can read which list the For Each iterates without having to click it!

We currently have the capability to create structures using a JSON editor, but it lacks the functionality to edit or update them. I propose implementing a feature that allows users to edit and update the structure directly within the JSON editor.

A module in Service Studio will register a "change" when viewing data from an entity in some contexts, requiring the developer to either re-publish or to click "Don't Save" when closing the module: If a developer is only viewing data, no changes have really been made, right? I would prefer not to have to click this "Don't Save" button. Below are the different contexts I tested and whether a "change" occurred as a result. Option 1: "View Data" on a static entity on element defined in the module Result: no "change" Option 2: "View or Edit Data" on a regular entity on element defined in the module Result: no "change" Option 3: "View Data" on a static entity that is being consumed from another module Result: a "change" occurs Option 4: "View Data" on a regular entity that is being consumed from another module Result: a "change" occurs