Hi OutSystems Team, In the OutSystems Support channel , implement a time tracking rule based on SLAs , as some clients use this metric and end up counting elapsed time, which is incorrect. When the issue remains on the client's side, the SLA should not count, or if the client "disappears" and does not close the ticket, this time should also not be counted. This helps OutSystems protect itself from misunderstandings and potential penalties (fines) from the client, which could lead to misinterpretations. The current view considers tickets as either open or closed. Time tracking helps with OutSystems' resolution metrics and protects the company from other interpretations and metrics. It would be beneficial if this data were exported along with the ticket ( spreadsheet generation ).

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/ .

As a developer I want to be in control on which ServiceActions or Events can be used in ODC Workflow. Just to make sure no big mistakes can be made by users not fully trained as developers. Ofcourse I can put them together in one app and make agreements with my Workflow users. But it would be much more convenient and robust to have a property on my Service Actions and Events where I can set if it they are allowed to be used in ODC Workflow

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

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! 🙂

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.

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).

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.