It would be very helpful to have a consolidated view of all Consumed APIs and Site Properties within the Service Center, under the Factory tab. Currently, when moving from one environment to another, it's difficult to track where each API is being consumed. Even if we know the API is in use, we still have to manually navigate through each application, then into the module, and finally into the integration settings to make changes. The same challenge applies to Site Properties. Having everything in one centralized location would streamline the process significantly. Open to any suggestions! 🙂

I would like to be able to consume REST API's with Swagger/OpenAPI version3 definitions. It would also be nice to be able to import YAML, instead of  only JSON.Another nice thing would be to be able to use API's documented via https://app.swaggerhub.com/ .

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

A "GetMonthLastDay()" function that receives as input a specific date and retrieves as output the last day of the month provided (i.e. 28, 29, 30, 31). Something similar to this: This can be very helpful when handling custom date widgets with no day to choose and you still want to filter the range from day 1 of a month to the last day of some future month. Also useful when you want to know if some date belongs to a leap year (or not).

please add auto adjust action flow

When creating an entity diagram, have the ability to hide the attributes. This would make it easy to see the relation between entities easily.

Hi,I believe that can be a good improvement to have the possibility to disable an REST/SOAP method from our exposed APIs.With that we can maintain versions with methods under work without the need to have different versions and, I believe it's more practical :)  (like the "disable" capacity in the action flows).The idea is to have them under the API but not available to use and not present in the generated documentation.Best regards,Ricardo Pereira

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.

It is difficult to track down a version of a forge component once you have installed it in your environment and the component receives new updates from the community.It should be easier to check how far behind I am in adopting a newer version of a particular forge component by just going to Service Center or best in LifeTime itself.Based on a trustable hashing algorigthm, why can OutSystems not determine if the package hash for the version of Forge component is matching with a signature with a published component and if so flag it to me easily. If the match does not happen then tell me that I have customized the copy of forge component so it is not possible to track it against the public repository.

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.