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

It would be awesome if there was the possibility of Uploading & Publishing multiple modules at once through Service Center.

With the introduction of Reactive, it is not possible any more to get user session data. That is probably a technical choice or limitation. The service center application now manages the user session and its data are not accessible. It would be great if an action is added (to service center) to terminate a user session by the user id. This feature is really useful and will help in managing users and do auto logouts. Now we have to keep a shadow session management on top of OS to do such things.

Add the possiblity to configure the Expose Read Only property when importing an external table via integration studio. This comes in handy when importing reference data tables from another system where you don't want the ability to write to the table, preventing create, update or deletes by not having those CRUD operations inside the extension module.This would mitigate data accidents by devs and truly feel like a static entity but only external.

To have a 'Find Usages' function for API clients created in ODC portal. When we expose API thru libraries, we can add ClientId and ClientSecret as settings. Then we will add the values, in the actual consumer app settings in ODC portal. Since there can be a lot of application using same ClientId and ClientSecret, it will be useful to have a 'Find Usages' for the actual API client created. This will allows for easy governance, and also ensure the correct app is using the correct API client.

To keep the code cleaner and avoid circular dependencies, it would be interesting not to let a module publish when you had to create circular dependencies.

It is just a minor issue but it happens that I want to change the order of the variables in an Assign.

Hi Everyone, When working with large modules that have many entities, adding entities to the Entity Diagram becomes difficult. The list is too long and there’s no way to search or filter it. We have to scroll through everything to find the entity we want. In projects with lots of tables, this takes time. It would be really helpful to have a simple search box or filter option when adding entities to the diagram, similar to other search inputs in Service Studio. Even just typing a few letters to filter the list would make things much faster. I believe this would improve productivity, especially in bigger applications. Thanks!

Service Studio prevents creating foreign keys that reference a static entity defined in a Library module.This makes sense for Protect and Delete rules, because the static entity defined in a Library module is not backed by any database tabe.However, IMO nothing is preventing us from using a foreign key with Ignore rule. These foreign keys will not have any database constraints, and will just be syntactic sugar to their underlying type (Integer, Long Integer or Text) but with the additional type checking and suggestions we come to expect from Identifier types.For example, it should be possible to define static entities that augment the capabilities of OutSystems UI by using this pattern, as described in https://medium.com/@leonardo-monteiro-fernandes/extending-static-entities-part-1-bec8b3b7631cThis would also allow values obtained from SOAP enumerates (which are mapped to non-persistent static entities) to be stored in database entities, without discarding the type information.

Every once and a while, one needs to perform bulk operations on data, and to get the best performance reccurs to advanced queries. The thing is that these widgets aren't "designed" for this ops (one has to always insert output parameter, when no parameter is required on these cases), so my suggestion is : Create some new built-in widgets for this ops. Best Regards, Diogo C S Cordeiro