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.

Inside an aggregate comparing the same variable (inside a filter) should trigger a warning. If an aggregate filter says user.id=user.id it should trigger a warning clearly this will always be true. the user would have likely meant user.id=userid

This looks more like a bug, but as per requested by the Support team here the details: Apparently, containing special chars like : in the URL is problematic. For example, for the official Google Maps Routes API Endpoint: "/directions/v2 : computeRoutes", although set correctly and accepted in the URL Path in Service Studio: the path is still being read in runtime as: "/directions/v2 %3A computeRoutes" by ODC/Outsystems 11. Current workaround works to explicitly decode the URL in the OnBeforeRequest: However, since the platform allows special chars in the URL path in a REST Action and doesn't complain or notify, it does not seem right and would make a better UX whilst saving time to another developers like me in future to figure out what's the issue, how to solve and then implement.

For many times we need to check the history of changes to an action or screen, it is also interesting to compare with an earlier version. It would work with the following steps:1 - Click the right mouse button2 - Select the option to view the history3 - View the history with the name, modification date and an option to compare with the current version.Images1 - Option to view history2 - History window with the option to compare with previous versions

When changing locale of a screen, in multi-lingual applications, everything is translated, except validation messages. The validation message is displayed in the right locale when triggered, however, if the validation message was already added, and then the locale changes, the validation messages are not translated to match the new locale. To translate the validation messages, the user has to trigger the form validation again.

A native service studio plugin for Figma that doesn't just "import" but "links" components. Changing a padding value or a colour token in Figma should trigger a " suggested update" in Service Studio, allowing for" live code sync "between the design tool and the low- code IDE.

OutSystems certifications are highly valued by developers and organizations worldwide. However, unlike many other global certification programs (e.g., AWS, Microsoft, IBM), OutSystems currently does not issue Open Badges for its certifications. Open Badges are digital credentials that embed metadata into badge images, making them verifiable, shareable, and portable across platforms. They are standardized by the 1EdTech Consortium (formerly IMS Global Learning Consortium) and widely adopted in education and industry. https://www.imsglobal.org/spec/ob/v3p0/ By enabling Open Badge support for OutSystems certifications, the platform can: Increase visibility and recognition of certified professionals Improve integration with digital portfolios and LinkedIn profiles Align with international standards for credentialing Enhance motivation and engagement among learners Implementation can be streamlined using existing platforms like Credly, which many organizations already use for badge issuance. The cost and operational burden are moderate, and the benefits in branding, community engagement, and learner experience are significant. We hope OutSystems will consider adopting Open Badges for its certification programs to further empower its developer community and strengthen its global presence.

Would be great to have a simple option to set the destination as a new tab rather than existing tab (maybe a dropdown as the image below). This is particularly useful in client actions, there are work arounds to solve this but require actions to check environment or current domain and these are always harcoded in some way.

Most of the times I need to open Service Studio just to check code and I do not need to get the references. It would save a lot of time when we just want to check the code and not change anything

Just as all other elements, the custom exception could be public so that on consumer espaces you can have error handling for specific custom exceptions of the producer espaces. Showing what kind of exceptions are thrown in the tooltip of a user action would also be a good improvement