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.