Just like the option to export/download certificates, it would be great to have the same functionality available in the Achievements section as well. The exported file will give information about all the achievements under the achievements section.

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

For each of our native platform apps, I usually have three different versions running on my phone, one for each environment.the development  versionthe testing  versionthe current production  versionI identify these different apps by specifying a slightly different ICON for each environment.The DEV icon for development, the TEST icon for TESTING, and the plain icon for production.This helps because I can immediately see on the phone which version I am running when I touch the app to open it.This works well until it comes time to deploy the latest changes from Dev -> Testing -> Production.Immediately after deploy, I must then open the application, and upload the TESTING icon  again ( and upload the Production icon in the production environment. )How about a feature when editing the application inside service studio to upload THREE icons; one per environment. Then we wouldn't have to keep remembering to change the icon after every deploy.Thanks for your consideration.

Hi,My suggestion is that modules could reference a particular version of another module.This would allow teams to keep developing and evolving their modules and not being concerned about apps that are not currently being worked on becoming broken or needing someone to manually update them.This is a very common scenario in larger factories and even with proper architecture it will happen.The way I see this working in practice is tagging module versions as "stable" and any consumer could choose to reference "current version", which would be the same as it is now, or one of the "stable version".This extra concept of "stable version" might be needed otherwise we would always be selecting from a list of hundreds or thousands of versions.From a platform perspective I believe this is quite doable! We can already just clone any module and reference that one (thus creating a kind of stable version), the platform could do this behind the scenes and have that "hidden clone" as the Stable version.The biggest difference from what we can do now is that these clones MUST use the same physical tables of the main module! (as in: not creating new ones)It goes without saying that what I'm suggesting here is also the way most "traditional" languages work!Cheers,Hermínio

I would like to have a sort of a screen in the Service Center where all this information would be centralized and displayed, and where it would be possible to list all APIs and to navigate to the API edit screen from there.It is not the first time where I am in a project where it is used a middleware for APIs management inside the organization. And a problem that always happens when, for some reason, the middleware changes its DNS, so from xyz.whatever to azurexyz.whatever, is that to make the changes in all the currently used APIs I need to go espace by espace (or module by module) in Service Center, assuming that I don't need to go into SS to see where all APIs are located and I don't miss any of them and change one by one.I know it is possible to have this kind of list looking into the system entities, but I believe this should be part of the product because it seems to be commonly necessary.This would also help, in cases like the example, I described above, to make sure that we don't forget any API where the URL basis needed to be changed.

Make an upgrade path that can upgrade app from O11 to ODC. Make a clear checklist and check it against the application. The process must be secure and achieve with a minimum click.

 Problem: Validations are hard, time-consuming and error-prone. Currently, OutSystems structures only define shape, not validity. A lot of projects end up lacking validations because of the effort involved in developing and maintaining them across client and server side. Proposed Solution: Introduce a Schema primitive (similar to Zod and Valibot ) that would define the shape (fields) and also the rules (declarative validation definitions that validate the field contents at runtime ). It would be defined in Service Studio and have an IsValid runtime field that developers can check to assert the validity of the data. An Issues field (list of Issue ) would identify which fields are invalid and the reason. The Schema should be universal, meaning it could be used to validate data both on the client and on the server side based on the same declarative rules. I think this would greatly improve developer speed and application security in our OutSystems applications.

If there are any advance queries, replace that by aggregateDon't use foreach Loop in preparationDon't use if conditions in preparationi.e try to avoid if conditions in aggregateApply pagination on list pageDon't show more than 100 records on single pageMove JavaScript webblocks to bottom of pageDon't use preparation aggregates directly in screen actionsBefore using them in screen actions refresh themSuggested by  Suraj.

In OutSystems, when a user tries to access a specific page without an active login session , they are redirected to the login page. However, after successfully logging in, the user is not redirected back to the original URL they attempted to access. Instead, they are sent to the default portal or home page. This behavior can be inconvenient from a user's perspective. Users are forced to manually navigate back to the desired URL, which disrupts their experience, especially in scenarios where deep links or bookmarked URLs are involved. Proposed Solution: Modify the authentication flow so that if a user is redirected to the login page due to an inactive session, their original URL is preserved. After a successful login, the user should be redirected to the URL they initially attempted to access, rather than the default portal or home page. Benefits: Improved user experience and satisfaction. Enhanced support for deep links and bookmarked pages. More intuitive behavior aligned with common expectations for web applications. This enhancement would make OutSystems more user-friendly, particularly for scenarios requiring frequent logins or when users access the application via shared links.

Show who are the users online and currently working in this shared environmentThis future will be really useful to improve joint working culture.If the user is publishing then it will show their status as publishing.If they just working on it then it will show their status as online.If the user is not using the environment then it shows his status as Offline.It will help other users in the shared environment to avoid publishing at the same time.