Dropdown search widget required default mandatory validation message. Need to add validation message and Mandatory message in Dropdown search widget. Developer and Front-end users will get benefits.

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.

It would be very useful to have a system event similar to OnApplicationReady but like OnSessionEnd or OnSessionExpire. The idea would be that whenever the user's session expires, the event is triggered and the necessary actions can be taken when the session ends.

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

Provide the ability to set the extended properties on reactive emails in the same way they are available in traditional. There is currently no way to set extended properties on reactive emails, this currently means we will have technical debt in maintaining an secondary application purely to send emails to enable setting importance, out of office suppression, expiry etcThe following is an example of the traditional extended properties in a traditional emailThe above is used to suppress out of office messages for mailings and prevents a deluge of out of office responses when a number of emails are sent.Importance is set on some emails based on the business process being followed e.g. high risk/value the importance can be set to High and the email client shows the importance of the email.The extended properties on the email has solved a number of issues with email visibility in a users inbox by adding the relevant property e.g. importance, sensitivity and also expiry has meant that processes that do rely on an email get the relevant attention required.

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

I would like to suggest two improvements that would significantly enhance the developer experience in OutSystems. Offline Development Support Currently, development requires a stable internet connection. In real-world scenarios (e.g., working while commuting or in low-connectivity environments), this becomes a major limitation. It would be highly beneficial to have an offline mode that allows developers to continue working on applications locally and sync changes once the connection is restored. Similar capabilities exist in other low-code platforms and greatly improve productivity. Real-Time UI Preview Without Publishing At the moment, verifying UI changes requires publishing the application, which slows down iteration. A real-time preview feature within Service Studio, where developers can instantly see UI/UX changes without publishing, would significantly speed up development and improve the overall workflow. Both features would reduce friction in daily development, improve efficiency, and align OutSystems with modern development expectations.

Allow "Dark mode" on New Service Center

 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.