I would like to propose the development of an API that allows integration with CI/CD tools to check for unused dependencies in an application. This API would provide a boolean value indicating whether there are any unused dependencies, enabling automatic detection during the CI/CD pipeline. By integrating this API into the CI/CD workflow, developers can easily identify and remove unnecessary dependencies, improving application performance and reducing resource consumption early in the development process.

Hi everyone, I would like to propose the creation of an official training path and a specialization certification focused on Digital Accessibility, covering both OutSystems 11 and OutSystems Developer Cloud (ODC). As Low-Code developers, we have the responsibility to ensure that applications are inclusive by deeply applying WCAG standards within Service Studio and ODC Studio. My suggestion is for OutSystems to offer: Accessibility Guided Path: A comprehensive training focused on using OutSystems UI accessibly, handling ARIA roles, managing focus, keyboard navigation, and testing with screen readers. Specialization Exam: A technical validation for developers who have mastered the implementation of accessible interfaces in Reactive and ODC applications. Profile Badge: An official badge on the community profile, allowing partners and clients to easily identify developers capable of delivering high-quality, inclusive projects. Why is this important? Market Differentiation: Accessibility-certified professionals are rare and highly valued by large enterprises. Product Quality: It reduces technical debt and ensures that "High Performance Low-Code" also means "High Inclusion." Platform Strength: It demonstrates that OutSystems leads the market not only in speed but also in social and technical responsibility. I believe an "Accessibility Specialist" badge would elevate the technical level of our community and help build a digital world for everyone. #Accessibility #Certification

 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

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

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