If you go to your customer portal, and you have a corporate infrastructure/environment and a personal environment, your personal environment is AWOL in the interface. Please can it show ALL infrastructures/environments please?

It is great that the OutSystems demo Homebanking apps are multilingual and also available in German. Nevertheless it is obvious the translation was not done by a German native speaker. In this way it is - to be honest - a little bit funny, instead of being a serious business app. E. g. the credit card VISA was translated as Visum in German language, which only means a visa for a country, not the credit card. And a lot of other stuff. English name -> curent translation - suggested translation Visa -> Visum -> Visa (I think it the same for the Portuguese word here: Visto) Home -> Heim -> Startseite Balance -> Gleichgewicht -> Kontostand Amount -> Menge -> Betrag Continue -> Weitermachen -> Weiter Loans -> Loans -> Kredite View -> Sicht -> Überblick Share Receipt -> Aktienquittung -> Quittung It would be great if these Homebanking apps (maybe others also) could be checked by a native German speaking OutSystems employee of the DACH-region.

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

Currently, OutSystems only allows limiting the total number of simultaneous process executions across the environment. There is no way to restrict concurrency per process type, which can cause problems when a single process spawns many instances. For example, starting 1000 BPT processes of the same type can consume all available execution slots, effectively blocking other processes from running. A per-process concurrency limit would allow developers to define a maximum number of simultaneous executions for each process (e.g., 4 instances at a time). Additional instances would automatically be queued until a slot becomes available. This feature would provide: Better control over resource usage for high-volume processes. Reduced risk of process starvation, where other processes cannot execute because one process is using all slots. Simpler queue management without custom throttling logic. Introducing per-process execution limits would make process orchestration more predictable and efficient, allowing developers to safely run multiple processes in parallel without one process dominating the system.

As we know, contact centres are underwater everywhere (as SNS24 in Portugal).The idea is to create a chatbot for FAQs that allow people to quickly get relevant information.We can use OutSystems.AI chatbot , integrated with the QnA service and integrated with some oficial knowledge bases (example: https://www.ecdc.europa.eu/en/novel-coronavirus-china/questions-answers ).Unanswered questions can be listed in a page, to be reviewed and added to the knowledge base, to make the chatbot smarter and smarter.The chatbot could then be highly improved if we allow humans to enter the loop and make the experience even smoother.

Allow entities Exposed Read-Only in O11 to have their Wrapper Actions explicitly mapped as well, and represented as entity actions in ODC. This would guarantee that business rules implemented in O11 are applied when accessed from ODC and eliminates the need for extraneous REST APIs solely for data integration purposes.

I would be great to be able to edit entity data (in addition to the ViewData functionality) inside Service Studio.As far as I know, there is no easy way to manually edit data for testing purposes.This is extremely helpful especially when bootstrapping data from Excel

Currently, when using an Input widget with Type = Number, it is not possible to set a Max Length for the field. This forces developers to switch the input type to Text and implement additional JavaScript, masks, or custom validations just to control the number of digits — which increases complexity, reduces maintainability, and removes the native numeric keyboard on mobile. Adding a Max Length property (similar to text inputs) would allow developers to: Prevent users from entering more digits than required Avoid using JavaScript workarounds Keep the input type as Number Improve UI validation consistency Increase development speed This enhancement would significantly reduce unnecessary logic and provide more control over numeric inputs without losing native browser behavior

Hi everyone, I’ve noticed something with the "Duplicated Code" pattern in AI Mentor that has been causing a lot of false positives in real projects. Right now, the detection seems to focus mostly on the Action flow structure (basically the “shape” of the logic). The problem is that many Actions in OutSystems naturally share the same simple pattern, like: Start → SQL → Assign → End So even when two Actions have completely different SQL queries and return different Output Structures, AI Mentor still flags them as duplicated just because the flow looks the same. In practice, these aren’t duplicates at all. They just follow the same architectural pattern. Trying to merge them usually doesn’t make sense, can hurt readability, and sometimes even impacts performance. Suggestion It would help a lot if the duplication check also considered the SQL widget details and the Action contract, not only the flow. For example, avoid flagging when: the SQL statement text is clearly different the Output Structure is different the returned data shape is different Maybe duplication should only be reported when the flow and the SQL and the outputs are very similar. This would make the detection more semantic instead of purely structural. Benefits Reducing these obvious false positives would: • Reduces false positives • Less time wasted marking valid code as “Won’t Fix” or "False Positive" • Prevents unnecessary refactoring that may hurt performance • Increases developer trust and adoption of the tool I think this small change could make the Duplicated Code pattern much more accurate and much more valuable in day-to-day development. Thanks!

Looking at the authorizations offered while creating the connection to MCP (Model Context Protocol), all the options related to (OAuth) ask for a client secret as a mandatory field. While searching on MCP Documentation, the client side must implement a PKCE (Proof Key of Code Exchange) flow, with this flow its not mandatory to have a client secret to get Authorization to interact with the MCP Server. Making a lot of MCP Servers impossible to connect to OutSystems. Where is the link for the documentation where they explain why PKCE flow should be mandatory: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#authorization-code-protection My suggestion here is to make client secret not mandatory.