Add native Passkey authentication support to OutSystems, enabling secure, passwordless login using platform-level passkeys (FIDO2/WebAuthn). Passkeys are becoming an industry standard (and for good reason) as they have multiple advantages over traditional authentication methods. From Fido Alliance: This could technically be implemented via a Forge component, but given the complexity and security criticality it would be much better if the platform handled it.

When we create a new solution with some Modules use missing or inconsistence dependencies or some Modules have outdated dependencies or some Modules are Offline or Modules have outdated dependencies that may be incompatible" in... Service Center > Factory >Solutions > New Solution It would be good if we could filter by type of inconsistence. This is happening on version 11.22.0. Best Regards, Paulo Russo . www.paulorusso.pt

Currently when we are trying to create a new idea for ODC, we get this warning: While I understand why this exists, it removes a key value of the community: visibility, discussion, and voting. If the problem is to ensure that the suggestion goes directly to the ODC team, wouldn't it be better to just notify said team when a new idea is created with the ODC category?

Our profile page has an Achievements section. While it is OK for regular users, some community members are too active in the forum for that to be searchable. That page becomes useless after a hundred entries. Can we have a filter like in Activity tab?

It would be nice to have a button, in ServiceStudio, to remove all unused references in an eSpace, or a list of unused references which we could then remove.

Hi, I found that 100 espace limit in a page was too few.I usually maintained Platform Server once in a few months.And it really a chore when deleting old versions of espace.Maybe add a configurable paramater instead of static 100 entries.

Sometime you work on a certain part and are not able to finish certain parts, or want to skip certain parts, like complex queries.Then it would be great to disable or, comment out certain tools in the action flow. so you don't have to worry about them now.Perhaps they are not complete yet, or unusable.With an if-block, it would always follow the true-line, it would skip the for-each etc. etc.

 Problem When using Aggregates, OutSystems requires that all attributes in the Output must either be included in the Group By clause or wrapped in an aggregate function (Sum, Count, Max, Min, etc.). In many scenarios, developers need to group by a single attribute but also display other attributes that are functionally dependent on that group. Currently, this forces developers to either: Add unnecessary fields to the Group By (which can negatively impact performance and change result granularity), or Use artificial aggregations like Max() or Min() just to expose the attribute in the output. This creates unnecessary complexity and may lead to confusion or performance issues. Impact More complex and less readable queries Potential performance degradation due to excessive grouping Workarounds that do not represent the developer’s actual intent Additional learning curve for new developers Expected BehaviorAllow Aggregates to output attributes that are functionally dependent on grouped attributes without requiring them to be included in Group By or wrapped in artificial aggregation functions. Possible approaches could include: Automatic detection of functional dependencies (e.g., attributes from 1-to-1 relationships) A configuration option to mark attributes as dependent on grouped fields More flexible output configuration in Aggregates Use Case ExampleGrouping orders by CustomerId while displaying customer attributes (Name, Email) that are uniquely determined by CustomerId, without requiring extra grouping or artificial aggregation. Business Value Better performance practices Cleaner and more intuitive queries Improved developer experience Reduced need for workarounds

In OutSystems, each Email Web Screen is counted as an Application Object (AO), and AOs directly impact licensing cost. In many enterprise applications, we create multiple Email-related Web Screens (for templates, preview, configuration, triggers, admin panels, etc.), which can significantly increase the AO count. My idea is to replace most Email Web Screens with an Extension-based approach. Instead of building multiple Web Screens for email management, we can: Handle email generation, templates, and logic inside an Extension Store email templates and configurations in the database Trigger emails via server actions or APIs without requiring dedicated UI screens How this helps customers: ✅ Reduces AO consumption by eliminating multiple Email Web Screens ✅ Lowers licensing cost for large-scale applications ✅ Centralized email logic in one reusable Extension ✅ Better performance and maintainability for complex email workflows ✅ Reusable across multiple modules and applications Example Use Cases: Transactional emails (OTP, notifications, approvals) Bulk marketing or system alerts Multi-tenant email templates per client Configurable email rules without UI-heavy admin screens This approach can help enterprises optimize licensing cost while still keeping email functionality flexible and scalable.

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