On ODC Studio when you create a new agent, there is a configuration named Call Condition. By its description and behavior it should be called Stop Condition to avoid confusion: It is already there when you open the question mark icon:

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.

Recently I often have to merge changes to the older environment, unfortunately, because this process is exhausting. The target environment is way behind (which is basically the reason why we need to use merge), and so the merge dialog pre-selects everything in the source module (as the newer version), and I have to spend a lot of time simply unchecking all that, because usually I need to merge only few elements. A module can be big and there can be conflicts, which turns this into nightmare. The quickest way I know is to go down with arrow key and use space to select, but every time when it hits the conflict - the popup dialog requires mouse click. To make things worse, sometimes studio does automatic merge, and it's not always possible to unselect it. Then after spending around 20 minutes on this, I find that the action was incorrectly merged, and this means starting again. Anyway, this could be significantly easier if there was an option to select everything from either source or target, and then you would go and modify only the elements actually needed.

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.

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

It would be nice to reorder the filters, etc. in the Aggregates view for organization purposes. Small but nice feature from simple queries.J.Ja

Sometimes you don't want to share your solution with the whole community but only with your co-workers. It would be great if we could have restricted Forge's on each account.Large customers with multiple infrastructures could use this company/private Forge to share reusable applications between their teams.

It does not take up any backend processing power, neither does it take up any storage space in the servers. It's all frontend. Why the cost of AO for using Local Storage?

The platform lack 3 commonly used math functions: - ceiling(decimal) - floor(decimal) - random(n, m): generates a number between n and m It would be usefull to have them built-in.

Not too long ago, we got For Each nodes to display the name of the Record List as its default label . Could we get something similar for Assign nodes with multiple assignments? Current behaviorWhen creating an Assign node with only one assignment, its default label becomes the name of the assignment.After adding 2 or more assignments, the default label changes to a generic "Assign" name. Proposed behaviorThe default name of the Assign node would be the conjunction of all common leftmost names of its assignments.If a common name cannot be resolved, then it defaults to the generic "Assign" name.Examples below: Example #1 - Common name "MyStrucutre.InnerStructure" Example #2 - Common name "MyStructure" Example #3 - No common names, defaults to generic "Assign" name RemarksThe "Assign" generic name does not add any value to the understandability of the code. Thus, any feature that attempts to display a meaningful label instead of this generic name is a valid product enhancement effort IMO.Good practices say that you should always custom-set the labels of your Assign nodes. However, as we know it, many assignments created every day by the average user are unlabeled.With the proposed behavior, developers are more likely to split big Assign nodes -- that contain assignments of different/unrelated records -- onto smaller Assign nodes (each containing values of one individual record) due to the automatic naming convention, improving code readability.