Life time should allow to create multiple plans that would be launched sequentially once the previous ended. Creating a plan should add It to a release pipeline, that would deploy the plans following a fifo method. This would solve deployment scheduling problems for large companies with multiple development teams and a single Lifetime.

Hi All,Can we have desktop-like default button-like behavior for mobile development?Like what we have on the login page on the mobile apps JS to listen to the enter event.Can we have this behavior out of the box within the platform or a widget in OutsystemsUI.thank youVitor.

It would be helpful to be able to import/export OML data about a module to a structured plain text file. This would allow developers to use git for storing code changes. Using git could solve branching/merging and code review concerns for changes to modules in the platform without having to build those features in Service Studio or other management tools. Features that would be helpful related to this Export an OML to structured plain text (xml, json, yaml, other). Import from plain text into service studio. Deploy using this format (ties into using third party CICD to deploy to various environments. Ideally, branching/merging, code reviews, unit testing would be more fully implemented in OutSystems but this feature would allow a "quick win" for teams trying to achieve this functionality.

Hi, Right now the system action 'ListAny' does not add extra benefits since you could also use ListFilter and check whether the list is empty, or use ListIndex and check if the returned index is -1. ListAny already returns a boolean, so why not implement it like an if-statement? With inputs List and Condition The current situation: In my opinion, the if-statement should not be necessary. It increases the amount of nodes and development time, and decreases readability. My idea:

Hi,Whenever we try to login without internet connection it still shows Invalid username/password ..Can we show a warning which says not connected to internet precisely.

Problem: xif and oml files that are uploaded to the Forge cannot be installed in the same way as oap files, which causes:Service Studio to not recognize when updates are uploaded to those componentsThe components generally get installed in Independent Modules and clutter the factory, which people sometimes don't realize until they try to move to the next environmentSuggestion: Disallow uploading xif and oml files to the Forge, and only allow them to be installed in an oap. Then go through the existing Forge components and cleanup ones that are just an xif or oml (either contact the owner, or wrap it inside of an oap)

OutSystems could introduce a feature where the platform automatically optimizes entities based on usage patterns. For example, when an entity is used in high-traffic applications, the system could dynamically adjust indexing, caching, and query execution strategies without manual intervention. This would allow developers to focus more on business logic rather than worrying about performance optimization.

It would be great if the list of forum posts could display the name of the person who posted the question. Currently, we can only see the name when we open the post, but it would be helpful to have this information visible in the list. We already display the name of the last person who replied, so it should be feasible to also display the name of the person who posted the question.

SEO friendly URLs only work on the default Outsystems application pool.Please implement it so that when you have multiple application pools (due to various reasons) the rules work, regardless of which application pool an application belongs to.

Currently, developers in OutSystems must publish their changes to validate them, which can result in unnecessary merges and conflicts in the published version, impacting other developers. By adding a “Test Before Publish” button alongside the existing One-Click Publish, developers can validate their changes in isolation before committing to the main application. This would significantly reduce unnecessary merges, minimize code conflicts, and introduce a branching-like development approach within OutSystems. To achieve this, we can enhance the system tables by introducing an additional entity to store a temporary test version (OML file). The process would work as follows: When a developer clicks “Test Before Publish”, their unpublished changes are stored in the new system table as a test OML version. The system loads and runs this test version in a browser, allowing the developer to verify their changes without affecting the published version. Once testing is complete, the developer can either: Proceed with One-Click Publish to merge the tested version into the live environment. Discard the test version if changes need further refinements. When a test version is published, the corresponding temporary test OML is deleted, ensuring no unnecessary version history is created in the system. Key Benefits: Reduces Code Conflicts: Developers can validate changes independently before merging, minimizing disruptions to other team members. Prevents Unnecessary Merges: Avoids publishing half-baked changes just for testing, keeping the main application version stable. Optimizes Version Management: Instead of creating multiple versions per developer, each user gets a 1-to-1 relationship with their own test version. Enhances Development Workflow: Aligns OutSystems development more closely with a branching strategy, improving efficiency and collaboration. Focus Areas & Considerations: Database Schema Changes & Data Consistency Since pointing tables remain the same between the actual and test version, database structure changes could affect the actual version. A strategy needs to be devised to prevent schema conflicts or ensure changes don’t disrupt the live environment. Resource Utilization & Performance Considerations Running a test version as an independent worker process could create additional load on the server. A more efficient way would be to execute the test version within the same application context, ensuring that no extra server overhead is introduced. Handling Application Hosting Since the test version is treated as a separate execution instance, we need to define how it will be hosted while still sharing the same application resources to prevent unnecessary performance degradation. By addressing these potential challenges, we can make the Test Before Publish feature a powerful addition to OutSystems Studio, enabling safer, faster, and more efficient development.