It would be relevant for us to be able to manage our certificates, to be able to remove expired ones to avoid conflicts on the platform, and to be able to renew certificates when emergencies arise. Having a view of our certificates without having to open tickets, and we end up wasting time trying to understand the problems, however I emphasize that the OutSystems team is 5-star. Or a lifetime option for access this information.

Everyone knows that descriptions are helpful to understand the meaning of a variable or anything. My suggestion is to show the site property description in the lifetime as we can see in the service center.

Hi,i recently got aware of a c# library named Polly . Polly is a library where you can define policies to handle execution results and exceptions and perform conditional follow up actions, like retries, retries with wait and others.We would strongly benefit from having an analogous feature in OutSystems esp. when consuming REST APIs. Especially when in need of* Rate limited APIs - APIs where you get an error when you hit the endpoint too many times within a specified timeframe.* Poll based asynchronous APIs - APIs where you initiate a job with one request and need to periodically check the result until you can request the final result of the job.* Unreliable API endpoints - APIs that sometimes time out because they are not well scaled or for any other reason. Requests sometimes time out and sometimes not.It would be a nice feature if we could specify Retry, Retry with Wait and Timeout Policies directly on the REST consume action with optional conditions, e.g.:Retry - max 3 times when StatusCode = 408RetryWithWait - max 3 times, Wait 1,3,5 secondsConditions should be possible to match not only the HTTP Status Code but also the response body. Poll based APIs typically deliver a status request with a code of 200 and the job status als JSON body attribute e.g. JobStatus so a policy condition could look likeWhen StatusCode = 200 AND Response.Body.JobStatus = "Pending"Such a feature would drastically reduce the manual handling e.g. in BPTs asf.Thank you,Stefan

As NextStep 2012 says 'Simplicity'.A switch widget on a webscreen will make the web screens more simple to understand!

As AI and Large Language Model (LLM) integrations become more common in OutSystems applications, developers need better ways to monitor and manage how these services are used. Currently, when calling APIs like OpenAI or Azure OpenAI, developers must manually track important metrics such as token usage, latency, errors, and estimated costs. This is repetitive and usually implemented differently in each project. This idea proposes a Forge component called AI Observability Toolkit for OutSystems that provides a standardized way to execute LLM calls while automatically capturing key metrics such as: Prompt and completion tokens Total token usage Response latency Model and provider used Estimated request cost Execution status and errors The component could optionally store this information for monitoring purposes and include a ready-to-use Screen Template (AI Observability Dashboard) that developers can select when creating a new screen. This dashboard would display metrics like AI request volume, token usage, latency trends, and estimated costs. This would allow developers to quickly add AI monitoring and observability to any OutSystems application, helping teams better control costs, troubleshoot issues, and manage AI-powered features.

Whenever we are on the viewing the widget tree of a page or Webblock, if we click on the "Go to <insert element here>" we continue on the same widget tree view mode and need to click again on the widget tree icon to finally see the element we selected as demonstrated on the gif below. The rationale is that if we are using the "Go to" context menu, 9 out of 10 times we want to open the original module to inspect/change the element selected.It would be nice that when we use the "Go to <insert element here>" context menu it would change to the view that actually allow us to "go" to that element

Hello OutSystems Community, When searching for components in the Forge, one of the critical factors for many of us is the Application Object (AO) count. This is especially important for managing infrastructure costs and complexity. The Problem: Currently, the only way to determine an asset's AO count is to open its details page. This process becomes inefficient and time-consuming when you are evaluating multiple assets to find one that fits within a specific AO budget. You have to click into each asset, check the number, go back, and repeat. My Idea: I propose adding a new filter to the Forge search sidebar that allows us to specify a range for the Application Object (AO) count. This could be a simple interface with two fields: Minimum AOs Maximum AOs This would allow us to instantly narrow down the search results to only show assets that meet our specific AO requirements. For example, a developer could search for all assets that have between 1 and 10 AOs. Benefits: Saves Significant Time: Drastically speeds up the process of finding suitable components. Improves AO Management: Allows developers and architects to quickly find assets that fit within their licensing limits or technical budget. Better Decision Making: Helps in quickly assessing the potential complexity of a component before even clicking on it. I believe this would be a small but powerful enhancement to the Forge experience for the entire community. If you agree this would be useful, please vote up! Thanks for your consideration.

Hello OutSystems community, I have a suggestion that I believe could significantly improve security in our applications developed on the platform. Currently, when passing parameters via URL, these parameters can be easily visible and even manipulated by malicious users. This can represent a significant vulnerability, especially when these parameters contain sensitive information such as user IDs, authentication tokens, among others. My proposal is to implement a functionality that allows marking input parameters on a screen as "Encrypted". When a parameter is marked as such, the value of this parameter would be automatically encrypted in the URL before being sent to the server. This approach would provide an additional layer of security, making it more difficult for malicious third parties to view or manipulate sensitive data transmitted through URLs. I would like to hear the community's opinion on this idea and whether it would be feasible to implement it on the OutSystems platform.

Hi Outsystems Team, I'm currently facing an issue where Service Actions do not receive the full set of client cookies , while Server Actions do. This limitation prevents the use of HTTPRequestHandler.GetCookie / SetCookie inside Service Actions in real scenarios. 📌 Problem When a request reaches a Screen Action or Server Action, all browser cookies are forwarded to the action's execution context. However, when calling a Service Action, only a small subset of platform‑managed cookies (e.g., UserId, TenantId, etc.) is available. This means: Custom cookies created by the application never reach the Service Action. HTTPRequestHandler inside a Service Action cannot read or modify these cookies. Some patterns related to authentication, tracking, and user context become difficult or impossible. 🔍 Expected Behavior Ideally, a Service Action should be able to: Receive the same full cookie set that Server Actions receive. Support HTTPRequestHandler.GetCookie and SetCookie. Allow more advanced use cases such as: Authentication extensions Cross-app user context sharing Tracking / analytics A/B testing Custom session or preference handling 🎯 Why This Matters Many modern architectures rely on Service Actions as: Shared reusable service layers Abstraction layers across multiple applications Integration or cross‑module processing points Centralized logic for authentication, tracking, and user context Without access to client cookies, these Service Actions become: Harder to design Less reusable Less aligned with real-world requirements This directly affects large-scale multi-app environments. ❓ Questions for OutSystems Is there a recommended way to forward all cookies to a Service Actio Is this a platform limitation or an intentional design restriction? Is there any roadmap to allow Service Actions to access the full cookie context? For now, we rely on a Server Action to read the cookies and pass them as input parameters. Is there a better official workaround? 💡 Additional Notes We do not need to modify platform-managed cookie. We only need to access custom cookies generated by the application. Everything works perfectly in Server Actions — the limitation occurs only at the Service Action layer. 🙏 Conclusion I would like to propose a feature that allows Service Actions to: Receive all client cookies, or Optionally specify which custom cookies should be forwarded This would make Service Actions far more flexible and suitable for real-world multi-application use cases. Any insights, confirmations, or guidance from the community or OutSystems staff would be greatly appreciated. Thanks in advance!

Today, AI Mentor (App Generator) is powerful when it comes to validating best practices, architecture, and quality of applications already developed in OutSystems. My proposal is to expand this capability so that the Mentor can read external source code (for example, from a Git repository, in languages such as Java, .NET, Node.js, Angular, etc.) and: Analyze the structure, business logic, integrations, and existing architecture patterns in the legacy code. Automatically suggest how this code could be rewritten in OutSystems, following modularization, security, and scalability best practices. Generate initial components (entities, actions, APIs, UI blocks) inside an OutSystems module as an acceleration base for migration. Value for the Community and Customers Accelerated migrations: companies with legacy systems could move to OutSystems much faster. Reduced risk: the process would become more predictable and auditable. Productivity: developers focus on evolution instead of manual migration work. Governance: the automatically generated application would already comply with AI Mentor’s best practices. Example Use Case Migrating a management system in .NET/SQL Server to OutSystems. AI Mentor connects to Git, reads the code, identifies entities, logic, and integrations, and suggests a skeleton in OutSystems that developers can refine. Expected Impact Disruption in the modernization process of legacy applications. Competitive advantage for OutSystems compared to other low-code platforms. Faster adoption of the platform by large enterprises with extensive legacy systems.