P10 introduced new operations over lists: ListAll, ListAny, ListFilter, ListIndexOf and ListSort.But, it's still missing a very usefull operation: ListDistinctWe are still using SortRecordList  extension just because of this functionality. It would be nice if it could be added to the system module.

An entity foreign key attribute has a Delete Rule property which can be set to Protect, Delete or Ignore by a developer in ServiceStudio. A Performance Best Practice is to set this to Ignore, but that could lead to database inconsistencies. Therefore, during development, it is safer to use Protect. This means developers need to remember to set this rule to Protect during development and then to Ignore after testing has been completed and before deploying to production if they want to conform to this Performance Best Practice.You can imagine this process is prone to errors. So how cool would it be if you could set a Platform Default Delete Rule per environment in LifeTime or ServiceCenter and then be able to select 'Platform Default' as the Delete Rule in ServiceStudio?So, for example, in DEV & QA the Platform Default Delete Rule could be set to Protect and in PRD it could be set to Ignore using LifeTime or ServiceCenter. Then, when a developer chooses 'Platform Default' as the Delete Rule on a foreign key in ServiceStudio, the platform makes sure that the Delete Rule is set to Protect on the database when Publishing/Deploying to DEV and QA and that the Delete Rule is set to Ignore on the database when Deploying to PRD. So the platform automatically sets the Delete Rule on the different environments according to Performance Best Practices!

Sometimes you want to compare text outside of an aggregate in a case insensitive manner.  To do this you need to enclose both sides of the = in ToUpper or ToLower functions.  It would be nice to have an operator to shortcut this.Something like: var1 ~= var2Instead of: ToUpper(var1) = ToUpper(var2)

As the community grows, we get an increasing number of inactive users.As natural as that is for any social network, that also means we'll have an increasing number of outdated Forge components .I believe that goes against the goals of helping the community with brand-new, cutting edge components.Whenever I find a component that I'd like to use, but it's old and/or deprecated, I try to convince their authors to add me onto their team so I can update it. A recent example is the CodeMirror component , which stopped receiving updates since platform version 7.However, that does not always work. If the author of a given component went inactive, his/her component lays there forever and nobody else can update/improve upon it.An example is the TinyMCE component, for which I tried to contact its author asking him to accept me into his team so I can update it ; since I didn't hear back from him, I had to upload a separate component named InputToTinyMCE, ultimately splitting the same plugin into two components and forcing the community user to decide which of the two should be used.I have a couple of suggestions to overcome this situation which I expect to become more and more common in the future years.Disable components (so that a new one can be created with the same name) that do not have a version compatible with the latest 2 major platform versions (e.g. P9.1 and P10) -- after giving a prior notice to its author(s).Allow other users to join teams whose components haven't received new versions in a while (maybe taking into account a minimum required community rank or forge score for security reasons).If items 1 and 2 are not applicable: any other mechanism that allows new users to contribute to "dead" components that may clutter Forge in the long run.

The idea is to right click a screen aggregate and convert it to a data action that has the same aggregate inside the flow and as Output parameters the sources of the aggregate. This could accelerate the process of building an output of an already existing screen aggregate that needs additional logic.

The property "Cache in Minutes" can only be set with an integer value, it would be nice if in the future this property could be set by a variable, like for example with a site.property.

Currently, if you want to integrate with Amazon DynamoDB, a popular NoSQL database service provided by Amazon Web Services (AWS), you would need to use a Forge component called Amazon DynamoDB Connector. This Forge component provides pre-built connectors and actions that simplify the process of integrating OutSystems applications with DynamoDB.Simplified development: With native support, developers wouldn't need to rely on a third-party Forge component. They could directly access DynamoDB functionalities through Integration Studio, reducing the need for additional installation and configuration steps.Enhanced productivity: Native support would provide a seamless development experience within the OutSystems environment. Developers could leverage visual tools, such as drag-and-drop actions and configuration wizards, to quickly build integrations with DynamoDB.Standardization and stability: OutSystems could ensure that the integration with DynamoDB is well-maintained and kept up to date with the latest changes in DynamoDB's APIs. This would provide developers with a more stable and reliable integration option.Easier learning curve: By incorporating DynamoDB integration into Integration Studio, OutSystems could provide documentation, examples, and tutorials specific to DynamoDB, making it easier for developers to learn and utilize the service.

 https://www.outsystems.com/ideas/2555/Unused+variables%2c+actions+or+functions+should+give+a+warning+on+TrueChangeFollowing up this idea, it would be expected to have the same behavior on unused Session Variables  and Site Properties

It would be beneficial to have a ‘ Prevent Publish ’ button for situations where we open a module solely for reference. This feature would help avoid accidental publishing when we only intend to view the module. Additionally, since merging is now automatically handled by OutSystems, this option would further ensure that no unintended changes are published.

When publishing a solution via Service Center, a lot of actions are performed. Very soon after the publishing started, you don't see the current action anymore unless you scoll down. Wouldn't it be possible to change the order of the list and put the newest actions on top? This way we can always which step is being executed without constantly having to scroll down to the end of the page. And while changing that, add the current timestamp in front of each row. ( https://www.outsystems.com/ideas/992/ ) It is always interesting to see at a glance when the last step was started or how long specific actions took.