OutSystems deployments always include all actions and resources, even when some are: Debug or experimental Environment‑specific Not intended for higher environments This increases deployment risk and forces developers to use workarounds (deleting, cloning modules, or manual discipline). Proposed Solution Introduce a way to exclude specific artifacts from deployment, similar to .gitignore. Examples Mark Actions / Files / Folders as “Exclude from Deployment” Or define ignore rules per app/module (e.g. /Debug/*, /Resources/MockData.json) Optional: environment‑specific rules (Dev vs Prod) Benefits Safer deployments Cleaner production environments Better DevOps and CI/CD workflows Less technical debt This feature aligns with modern development practices and would greatly improve developer experience in OutSystems.

Hello everyone,Currently, we have the option to align and distribute the items in an action flow by selecting multiple items, and right-click the selection subsequently. But I think there is room for some improvement. I'm not sure if it's feasible (for bigger action flows), but I thought it would be nice if there was an option to beautify your produced code with one click, based on some common best practices.For me, it increases readability if the spacing between items in an actionflow is the constant for example. In the image below I exaggerated the issue a bit, but it clarifies the idea that I'd like to suggest.I'm curious to hear other thoughts on this topic.Sam

Hi all,On Reactive web apps it's no longer possible to add variables on the screen title, it only allows text.Reactive:Web tradicional:I think it's good thing to have because if a customer has a lot of tabs open, he has to open each tab to find the "order" that he wants to see.Thanks!Miguel

I feel like a rollback or retract lifetime feature might be extremely beneficial for large applications with lots of dependencies. Currently, if I deploy a long deployment plan and something goes wrong in prod I have to either fix it immediately or manually rollback to a previous version for each module that was published. I want to be able to rollback or rather retract the last deploy with a button click.

The Base URL for consumed REST services should be configurable at runtime:In some cases (like the JIRA Cloud REST api), the base URL of the web services varies according to the account used to access them. Since the URL is hard-coded in Service Studio (it can be overridden in ServiceCenter but the setting applies to all users accessing the REST api), there is currently no way to configure this based on the tenant being used or the user that logs in.

It would be (very) nice to be able to copy/past, at least actions and structures, from one extension to another.

On the scenario that, there is:- A End User espace A, that consumes a weblock on a UI espace B,- The Weblock on espace B consumes a action from CS espace  C- There is no reference between A and COn the described scenario currently is no possible to debug on C request from start on A without adding a useless reference between From A to C

If we can enable a holiday period for our personal environment, it can save us trouble and inconvenience of having our apps deleted. Thou to ensure this is not being abused, when we set the holiday, there must be a start and end date. And maybe some validations, eg not more than 2 months etc...so that we will not be able to set for 1 year or something. Of course, the time period, will not be able to please everybody. Then after this holiday period ended, the existing control can comes in, eg. if not logged in for 2 weeks, then deactivated and eventually removed Think this is good, as I sometimes do go on a slightly lesser than 1 month holiday, and will not be able to log in.

 Problem Debugging Reactive screens can be difficult when developers need to understand the current state of local variables, client variables, input parameters, screen data, and browser storage. How this suggestion can help A dedicated Reactive Debug Panel would give developers a centralized view of the screen state during runtime, reducing the need for temporary labels, console logs, or manual debugging workarounds. Implementation example Add a debug panel available during preview/debug mode showing: Current Screen: RequestDetail Local Variables Client Variables Input Parameters Data Actions Local Storage Session Storage The panel could allow developers to inspect values in real time and optionally copy them as JSON.

 Problem In large modules, unused local variables, input parameters, output parameters, and assignments can accumulate over time. This makes the code harder to maintain and can confuse developers during debugging. How this suggestion can help A better unused element detector would improve code quality, reduce technical debt, and help teams clean modules before publishing. Implementation example Service Studio could show warnings such as: Local variable 'TempStatus' is never used. Input parameter 'RequestId' is not referenced. Output parameter 'SuccessMessage' is never assigned. It could also provide a quick action: Remove unused variable