Just like in Traditional Web, it would be nice to have a simple way of translation prompts/text/static entities.

With the introduction of the Dynamic Case Management Framework, OutSystems advocates to use GUID as a unique Text Identifier (see https://success.outsystems.com/Documentation/Case_Management/Create_a_case_management_app ).Apart from that GUID as identifiers have some other use cases too:Less "hackable" URLs to your application pages than when using Integer IdentifiersLess meaningful Identifiers (Employee number 2 is probably longer with the company than Employee number 58)You want the data to be uniquely-identified, no matter where it came from.You need to be able to combine data from difference sources with little-to-no chance of duplicate GUIDs.Furthermore, you don't want or don't care about the users needing to remember an ID themselvesIt would be nice if there is more support in the Platform:Add a new datatype called GUID, with an AutoNumber option.Add a popup menu option to generate a GUID and set it as a string literal for any attribute of datatype GUIDAdd built-in feature to also generate a GUID for Mobile and Reactive, as it is currently only available server side. Yes Forge component exists to help you, but this should be build in.

Allow "Dark mode" on New Service Center

This idea is to suggest that the zoom level in expression editors should be preserved between opening/closing the editors. Example: 1) Open an expression editor 2) Adjust the editor zoom to 200% (CTRL + Scroll Wheel) 3) Close the editor 4) Open the editor again 5) Zoom is back at 100% 6) Increase the zoom again. 7) Repeat 100 times in a day. To reduce eye strain I often increase the zoom in expression editors but as soon as I close the editor the adjustment is lost. Maybe there's a way to keep the zoom preference 'stick' while a service studio instance is open. Thanks, João

Hello community! Today, I want to talk about an idea that I believe may not be entirely new, but I haven't seen many approaches to it, so I decided to write it in a more structured way. (The most similar idea I found was this: Translation Teams ) The idea is allowing community members to contribute in translating OutSystems documentation. I'll explain why and how I envision this implementation. Why? Regardless of the language we speak, we all prefer reading and hearing our mother tongue, as it resonates differently in our hearts. A study in the NeuroImage journal concluded that there are structural differences in the brain connections of people with different native languages. ( Native language differences in the structural connectome of the human brain ) If our mother tongue influences our brain in this way, it will undoubtedly impact how we learn, whether in our native language or in a language learned later in life, such as English. Considering this, I believe translated documentation can significantly enhance a user's information processing, accelerating their learning and development . But what about English? We all know it's crucial for developers to read and communicate in English for various reasons. Documentation helps in this! Yes, I don't deny that. My goal is not to translate all content or dismiss English . I propose implementing translation to help in studying/understanding documentation. How? The idea is simple. Community members submit translated documentation to OutSystems. The translation team (if it exists) reviews and, upon approval, makes it available. Questions may arise: How many languages? Translating documentation into every language is unrealistic. Initially, I suggest translating into the world's top 5 or 10 most spoken languages, covering a large audience and gauging project success. Members suggesting translations? That's crazy! There could be errors or trolls! Various measures can prevent these scenarios. I propose limiting the number of members suggesting translations: - Only active or higher-ranked members can suggest translations; - Members with specific certifications/proven technical knowledge can suggest translations; - Only MVPs or Champions can suggest translations; - Members must apply for a "translation program", proving linguistic abilities for specific articles/languages; - A combination of the above. Members could use tools like Google Translate or AI! True. For that members might be evaluated for translation skills, and OutSystems could verify translations. Using translation tools doesn't necessarily mean poor quality; it just requires validation. OutSystems just did this with AI translation for Japanese! Yes and no. While OutSystems' implementation is excellent for forums, it may not suit documentation. AI may not grasp documentation contexts, leading to empty translations. Reliable translations by professionals understanding the original message, context, and technical aspects would be more valuable than AI translations. This is my idea. It's complex and may not be as easy to implement as it seems. It would take time and effort, but I believe it would be a great addition to this constantly evolving community in need of skilled developers. This implementation would not only expand OutSystems' reach but also enhance every user's experience and learning! Please share your thoughts on my idea. If you have questions, ask, and I'll respond if I can. Support it if you find it valid and would like to see it implemented. Cheers, Mauro Alviza

This idea proposes a built-in visual tool that validates API requests and responses against their defined contracts, such as Swagger or OpenAPI specifications. The tool would automatically detect missing fields, incorrect data types, and deprecated attributes before or during runtime, helping developers catch integration issues early. By making API contract validation visible and easy to understand within OutSystems, teams can reduce production defects and integration failures without relying on external tools or manual testing.

In Client Web applications, when performing custom validation on a Form, developers cannot directly set Form.Valid manually. This creates a limitation in advanced scenarios where validation conditions can't be fully handled by the built-in validation framework. For example, if a developer wants to invalidate the form based on a business rule such as: Number < 100000 there’s no way to directly set: Form.Valid = False Instead, developers are forced to: Create an extra local boolean variable to store the validation result Reuse the same condition again when checking whether to proceed or show an error This results in code duplication, reduced maintainability, and extra steps for logic that should be simple. A better approach would be: Allow manual control of Form.Valid — enable developers to set it to True or False inside client logic flows or expressions Or introduce a built-in method like Form.Invalidate() that can be triggered conditionally, without relying solely on form input widgets This would: Simplify complex validation scenarios Reduce the need for extra variables and duplicated conditions Improve logic readability and maintainability Let developers manage validation state more directly

The idea is to add the possibility to classify the type of advanced query we need. This is very important because when we are using a SELECT query, we need to insert the output correctly. But when we only want to create an UPDATE query or a DELETE query, e.g. bulk update or bulk delete, the output structure is not important and by classify, for example, we don't need to insert an output chosen by us.Another example of a rule applied using this type, there is no need to insert a TOP in the DELETE or UPDATE queries and of course no Max. Records.

When working on a large project it is common to do fairly much the same deployment each sprint into our QA environments. It would be great if we could setup the deployment in lifetime, give it a name and save for future deployments. We can sort of do this at the moment but you can only have one saved plus it saves the current versions of everything so if espaces are updated in the source environment you don't get those updates when you finally go back in and deploy the saved plan. It will still need to run all the normal validation checks each time and allow us to add additional applications before hitting the deploy but would at least save time adding all the same common ones each time. Yes we could do this by creating a solution and deploying via servicecenter but then it is a multi step process and we don't get all the additional reference checks and auto including from the validation step.

If I have applications installed from Forge like "SilkUI Framework" or "Google Maps", Service Center and\or Service Studio could notify me if there are newer versions available.This way Forge would work like a real App Store and notify the users each time a new version of an app is available, and with a click we could instantly update those apps.This option should be configurable from Service Center \ LifeTime.