When tagging someone in the OutSystems Forum using @, multiple people with the same display name can appear. This makes it unclear which person you are actually replying to. To improve clarity and avoid confusion, I suggest these options: Enforce unique usernames that each user can set for themselves. Display this unique username with name consistently across the forum (profile, comments, and mentions). In the mention dropdown, show both name + unique username so members can easily identify the right person. Or We can also go with an easy step, which in the forum email should be displayed with the name, and also in the mention dropdown This will make communication smoother and ensure that members always tag the correct person in forum discussions.

So you don't accidentally publish a full solution on your production environment, thinking you're on DEV. It could be taken a step forward, by changing Service Studio's menu color to the one of the Service Center it's connected to.

Currently, the only way to share Outsystems code with LLMs or to show to a person on the forums, etc, is with a Screenshots, but a Screenshot cannot display everything at once: for example Input/Output parameters for several Actions in an Action flow in a single Screenshot. A single one side Service Studio -> Text Editor would open new doors, if you can Copy/Paste Service Studio elements in a text form to paste into LLMs or other text editors for AI code generations , context, creation of documentation, etc. It doesn't have to be perfect, it can be an imperfect, incomplete and invalid machine generated code (JSON, XML or any other text form, that is easier for the Service Studio team to implement), LLMs nowadays can quickly reformat it in a better form according to use case and extract whatever needed. It can help by virtually all of a module/application elements inside Service Studio, but among the most beneficial would be StaticEntities and Entities + attributes, Structures + attributes, Action in a flow (names + input/output parameters), etc.) in a text form. It is not the same as, but it would implicitly provide some solution for the problem from this idea: https://www.outsystems.com/ideas/11114/copy-multiple-property-names/

 Problem Statement In ODC, a Client Secret is required in virtually every scenario where an app communicates with external systems or calls ODC Management APIs programmatically: UsersManagement (Forge) → ODC User & Access Management API External IdP integration (OIDC) → Azure AD, Okta, etc. ODC REST API calls → Portfolio API, and others External service integrations → Salesforce, MS Graph, etc. The current behavior is that Client Secrets expire every 90 days by default (maximum 2 years), and renewal is only possible manually through the ODC Portal. Root Cause of the Issue This is not merely an inconvenience — it is a structural constraint that breaks the promise of full automation in ODC-based services. Here is why: ① No programmatic renewal path exists There is currently no Management API endpoint to rotate or renew a Client Secret. This means that no matter how well-automated your app logic is (e.g., a Timer-based user management flow), the secret renewal step always requires direct developer intervention. ② Expiry creates operational risk at scale In production SaaS or B2C environments running on ODC, a missed secret expiry means: All features depending on that secret stop working silently or with cryptic errors End-users are impacted before the team is even aware Recovery requires Portal access by a developer with the right permissions — not something an end-user Admin can resolve ③ The expiry cycle creates recurring developer toil Even with the maximum 2-year expiry configured, and even with calendar reminders or monitoring in place, this is manual, recurring, high-risk maintenance. It runs counter to the Low-Code philosophy of ODC: reducing developer toil and enabling reliable, autonomous operation. Requested Feature(s) Please implement one or more of the following: Option A — Programmatic Secret Renewal via Management API Add a Management API endpoint that allows an authorized app to rotate or renew a Client Secret before expiry. This would enable a Timer-based auto-renewal flow entirely within ODC, with zero developer intervention. POST /api/v1/clients/{clientId}/secrets/rotate→ Returns: new_secret, valid_from, expires_at Option B — No-Expiry Secret Option Allow trusted, internal service accounts to opt into a non-expiring Client Secret, similar to how other platforms (e.g., Azure App Registrations, AWS IAM long-term credentials) provide this option with explicit acknowledgment of the security trade-off. Option C — Secret Rotation with Overlap Window Support a dual-secret validity window during rotation — where both the old and new secrets remain valid for a configurable overlap period (e.g., 24–72 hours). This enables zero-downtime secret rotation in production environments.

It would be good to have CRUD Wrappers for Local Entities as we have for Server entities

Support datatype of jsonb, feature of Similarity Search, pgvector as vector database for LLM embedding storage.

It would be really good to have a list of all unconsumed public elements from a producer module.This would be of great help in 2 scenarios:- while review code from other developers- while working on an application that was developed by other teamsIt is very common that code gets developed with a purpose in mind, but somewhere down the line it becomes obsolete or ends up not being needed. If teams are not methodic, a lot of unused public elements end-up bloating up the module. I am currently working on a project developed during 2 years by another company. I constantly find unused public elements all over the place. They obviously are obsolete, and if my team needs some of that functionality, most likely we will develop from scratch rather than have to search if some code exists for the purpose we need. Hence, unconsumed elements are as pure trash on the application. But there is no way to make a bulk clean up. It would be great to be all to see a full list without having to go one by one.

 Idea Summary Improve the OutSystems Date Picker component to handle DateTime values more accurately and consistently by introducing timezone-aware options and ensuring correct date selection behavior across all data types. Issue Description The current behavior of the Date Picker in OutSystems is inconsistent depending on the data type it is bound to: When bound to a Date type, the selected date is passed and stored correctly. When bound to a DateTime type, the selected date often shifts to one day earlier than expected. This issue appears to stem from server-side time zone conversion, and it becomes particularly problematic in global applications, where users in different time zones experience inconsistent results. Key Improvements Needed Consistent Handling of selected date values regardless of whether the field is Date or DateTime. Time Zone Awareness to avoid unintended shifts due to UTC or server time assumptions. Developer Control via an optional toggle or setting in the Date Picker to treat DateTime values as local dates by default. Suggested Enhancements Add a "Treat as Local DateTime" option in the Date Picker widget settings. Ensure that when a date is selected, it reflects midnight of the selected day in the local time zone unless explicitly configured otherwise. Provide clear documentation or tooltip guidance within the widget for Date vs DateTime behavior. Impact of the Issue Off-by-one-day errors when storing or displaying selected dates. Increased debugging effort due to non-obvious time zone conversions. Reduced trust in date handling for end users, especially in global or multi-regional apps. Higher complexity in development when working with DateTime fields that should behave like Dates. Benefits of the Enhancement Eliminates unexpected date shifts and off-by-one-day errors. Simplifies development and reduces debugging time for apps using DateTime. Improves accuracy and reliability of date-related data across different regions. Enhances the user experience with a more intuitive and predictable Date Picker. Supports global applications where proper time zone handling is essential.

If we can enable a holiday period for our personal environment, it can save us trouble and inconvenience of having our apps deleted. Thou to ensure this is not being abused, when we set the holiday, there must be a start and end date. And maybe some validations, eg not more than 2 months etc...so that we will not be able to set for 1 year or something. Of course, the time period, will not be able to please everybody. Then after this holiday period ended, the existing control can comes in, eg. if not logged in for 2 weeks, then deactivated and eventually removed Think this is good, as I sometimes do go on a slightly lesser than 1 month holiday, and will not be able to log in.

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?