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

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

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.

 Problem: Even after years of development, maintaining consistent code quality across large teams is a persistent challenge. Despite the existence of best-practice documentation, junior and even senior developers frequently bypass critical standards—such as proper documentation, naming conventions, Max. Records settings, or inefficient operations like lists within loops. Currently, code review is a manual, reactive process that happens too late in the development lifecycle. Proposed Solution: I propose a new "Governance Gatekeeper" feature for Service Studio, powered by existing AI Mentor capabilities, that moves code quality from "suggestion" to "enforcement." Policy-Driven Publishing: Allow Admins to configure a set of "Strict Quality Rules" for specific modules. If the modified code fails to meet these pre-defined standards (e.g., missing descriptions, non-compliant naming, or performance anti-patterns), the 1-Click Publish button is disabled, preventing the deployment of substandard code. Granular Control: Provide the ability to toggle these restrictions on or off per module or application. This allows organizations to apply strict "Production-Level" enforcement on core systems while maintaining flexibility in "Sandbox," "Learning," or "PoC" modules. AI-Powered Feedback: Integrate the AI Mentor to not only block the publish action but to provide a clear, real-time "Action Plan" telling the developer exactly what needs to be fixed to unlock the publish button. Impact: By integrating automated enforcement into the development loop, we can: Guarantee Technical Debt Reduction: Prevent bad patterns from entering the codebase at the source. Scale Mentorship: Use the platform to train developers in real-time, effectively automating the role of a lead developer in enforcing standards. Elevate Enterprise Reliability: Ensure that all production-bound code meets a uniform level of quality, documentation, and performance before it ever hits the server. Thanks

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.

It would be great to have a test at the end of each "path" to verify if you miss something important. Also it would be great if that question will be at the same format as on the certifications exams.

 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.

As part of our ongoing effort to follow OutSystems best‑practice architecture, we have restructured our application landscape to clearly separate business logic from front‑end applications. While this approach improves modularity and maintainability, these applications still have interdependencies, which we group and manage as a logical Suite. When deploying to another environment using Lifetime, all module dependencies are automatically validated and republished as needed, and we are proactively notified of any breaking changes across dependent applications. This capability significantly reduces deployment risk and ensures consistency across the suite. It would be extremely valuable to have a comparable feature in Lifetime that allows us to publish a Deployment Plan within the same environment, while still performing full dependency validation. Ideally, this process would identify broken dependencies, prompt corrective action, and automatically republish all dependent applications as required. Implementing this capability would result in substantial time savings for developers. Today, deploying changes within the same environment often requires manually opening and publishing multiple modules in the correct order, with limited validation feedback and a high risk of human error. A unified, dependency‑aware deployment mechanism would both streamline this process and strengthen application stability. While we have implemented a workaround using Solutions in Service Center, it does not provide the same level of validation and dependency checks that Lifetime performs during cross‑environment deployments. Closing this gap would significantly improve deployment efficiency, reduce rework, and enhance overall application dependency management.

Some teams have been keeping technical documentation on a separate document format instead of generating using OutDoc to leverage, which makes this Indicator, especially in cases where the Application is not meant to be a component or widget, unnecessary.So, maybe if there was a Settings feature where we could set this Indicator as optional / mandatory for a given Application, it would be helpful.