Currently, ODC does not provide a mechanism to extract or automatically generate documentation for applications. In previous versions, such as OS11, tools like OutDoc and direct access to OutSystems metadata allowed teams to generate technical documentation more easily. The proposal is to introduce an AI-powered capability that can analyze an existing application or library within ODC and automatically generate technical documentation, such as: application architecture overview dependencies and libraries used module and component structure APIs and integrations main functional flows This feature would significantly reduce the manual effort required to create documentation, improve knowledge sharing across teams, and ensure that documentation remains up-to-date with the evolution of the codebase.

An often-occuring issue is that user click on an action twice, which causes an action to run twice. This leads to very nasty issues where data is created and/or processed twice. One way to prevent this, is to wrap your Button into a 'Button Loading' widget, and adding an IsLoading widget to the page. It would be nice to support this in an easier way, either by: Adding a property to the button that adds 'IsLoading' behaviour to it Add ButtonLoading widgets around all your button widgets in your apps Any other ideas to achieve the same result?

In ODC we should be able to open external logic files downloaded from Forge to check the code inside. Without knowing what is being done, we are just trusting in the actions comments without knowing exactly the logic inside and leading to possible privacy and security risks. O11 Integration Studio was more transparent on this. It was also more simpler and quick to create extensions.

Adding an option to send null values in JSON structures for objects and attributes is currently handled in the `onbeforerequest` event, and for very complex structures, this becomes very complicated. This would facilitate development.

I would like to see a built in midnight/dark theme for service studio. Something that is a little easier on the eyes when working the night shift.Looked around but couldn't find anything to suggest this is a duplicate, but let me know if it is.

I would like to suggest a logic clarification (or modification) to the training for the archiving. It's possible there has been an oversight, or the training may lead to a dangerously wrong solution, or I'm just an idiot. (More than one option may apply.) https://learn.outsystems.com/training/journeys/web-developer-exam-2993/data-archiving-best-practice/odc/7017 Here is the current logic in question: Text below it it, whole section pasted for clarity: Set Archive Threshold - Sets the number of records to archive by iteration. This threshold can be defined using a Setting, so it can be adjusted without redeploying the app. Set StartTime - Sets a local variable with the current time when the execution starts. CheckRecordsToArchive - Validates if there are records left to archive, according to the conditions defined using the control columns. Has Records to Archive? - Validates the output of the previous query and executes the archive branch if there are records to archive. MoveIntoArchiveStorage_InBulk - Executes a bulk INSERT INTO SELECT statement from the primary storage to the archive storage, combined with a clause to limit the amount of archived records (using the Archive Threshold set in 1). It implements the archive condition. MainStorage_SetArchivedFlag_InBulk - Executes a bulk UPDATE to set the IsArchived flag of the records archived in the previous step. Can Process More? - Validates if the current execution duration is approaching the Timer’s timeout (using an expression like DiffMinutes(StartTime, CurrTime()) < 15, for a default timeout of 20 minutes). If there’s still time, it continues checking for more records to archive. This approach helps prevent the Timer from timing out and having to repeat work. CommitTransaction - Commits the transaction to make all changes permanent in the database. WakeArchiveData - Re-wakes the Timer to check if there are still records to archive. My suggestion it that something should be added to step 6 " MainStorage_SetArchivedFlag_InBulk " to explicitly clarify that they should not use the exact same logic (where clause) used in step 5 to select items in step 6, because the data may have changed , leaving the data in query different. This will result in the wrong records being flagged as archived, and subsequently getting deleted by the clean-up process. They need to do some sort of check (inner join?) against the archive table. I understand this is an edge case, but we all know one in a million edge cases tend to happen within a week of functionality going live. Maybe there is an assumption that someone will know to do it this way, and I'm just being dumb, but the wording of the guidelines would tend to lead to someone reusing the same query logic, especially as an inner join query would be assumed to be much slower....? Does anyone from OutSystems training, or in fact, their business processes team, have any thoughts on this. It this a flaw in the training content, or in the archiving logic that was envisioned? Or am I just barking up the wrong tree here? (I'm guessing this scenario is used in the exam as well.)

Would be a (minor) quality of life feature if you could bind a label to an input if you simply drag and drop it from the tool box on the left straight on the Input widget. For example here, this widget is bound to a "Max records" local variable, to control how many records an aggregate returns. If I drag the label on to it, it could do several things: Add the label on top of the Input Set the Input Widget automatically on the Label properties, and give it a name like "InputName_Label" Set the text for the label on a 'best guess' case, depending on what the input is bound to (for example here, Max records) This could work for all other input type widgets: text area, switches, checkboxes, dropdowns, etc.

First off, the "Create Action Wrappers" feature is really useful. When you right-click an Entity and generate the Create and CreateOrUpdate server actions, the platform already checks for Mandatory attributes. If a developer misses assigning a value to a mandatory field, an exception is thrown at the application level. That's a nice touch and saves a lot of headaches. One thing I noticed though is that for Text attributes, there is no validation on the defined Length. So if a developer passes a string that is longer than the max length set on the attribute, the value still goes through to the database and you get the classic "String or binary data would be truncated" error. That's a database level error, not an application level one, and it gives the developer zero context on which attribute caused the problem. Since the platform already knows the Length property of each Text attribute (in the Entity definition), it would be great if the generated wrapper could also validate against it. Same pattern as the Mandatory check, just extending it to include a Length check for Text attributes and throw a meaningful exception before it hits the database. This could help by: Making the generated wrappers more complete and consistent Giving developers clearer error messages during development and runtime Reducing unnecessary database round trips for data that was never going to be accepted anyway Really appreciate how the platform already handles the Mandatory side of things. This would just be a nice extension of that same thinking. Would be great to have this for both O11 and ODC. Thanks for considering!

Enable to Test an Action giving new input parameters.

Implement a "Conflict-Free Data Replicated Type " (CRDT) based editor that allows two developers to work on the same screen or logic flow simultaneously, seeing each other's changes in real-time without needing a manual merge