Add something similar to "Export Action To Image" but with the actions objects numbered and a section below listing the parameters for each one . Also, a way to generate these in bulk , with it generating a zip file with them all inside, named appropriately, or as a PDF file.

Just like "Action's" folder allow user to add folders to the Entity and Structure tree.

An AI within the development studio/canvas that analyzes complex Aggregates and SQL queries and suggests performance improvements. For example, it could recommend creating new indexes, simplifying joins, using CTEs or temp tables or using more efficient filter patterns based on the data model and query structure. This could be a more granular version of the existing AI Mentor.

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.

We would like to request the implementation of a Drag and Drop File Upload widget within the OutSystems platform. This feature would significantly improve the user experience by allowing users to easily drag files from their local system and drop them into a designated area for upload. It should support multiple file types and sizes, offer visual feedback during the upload process, and integrate smoothly with existing workflows. Adding this functionality would modernize the platform and align it with current best practices for user interface design

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.

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!

Dear OutSystems Training and Certification Team, As the OutSystems platform continues to dominate the enterprise low-code market, more organizations are leveraging it to build highly visible public-facing applications, B2C portals, and marketing sites. Because of this shift, Search Engine Optimization(SEO) has become a non-negotiable requirement for many development teams. I am writing to formally propose the creation of a new specialization badge: Outsystems SEO Specialist. These specializations would validate the developer's ability to navigate the unique SEO challenges present in single-page applications(SPAs) on both Outsystems 11 and ODC, covering critical platform-specific implementations such as: Configuring clean SEO friendly URLs and site rules Integrating third-party pre-rendering services like prerender.io effectively. Managing crawlability sitmap.xml and robots.txt with the constraints of ODC and CDN layers. Optimizing core web vitals and DOM loading structures specific to reactive applications. By creating this badge, OutSystems will empower developers to build applications that are not only highly functional but also highly discoverable. Thank you for your time and continued effort to expand the ecosystems learning path Best regards OJJallow

Hello, It once existed... but it doesn't anymore. https://www.outsystems.com/ideas/1673/bundling-and-minifying-the-javascript-css-files/ When we publish a solution that has a mechanism to minifying CSS and JS - well, it could be a checkbox that the user chooses whether or not they want this option, and it might not be available in the free version... But that could benefit the performance of applications.

In OutSystems, each Email Web Screen is counted as an Application Object (AO), and AOs directly impact licensing cost. In many enterprise applications, we create multiple Email-related Web Screens (for templates, preview, configuration, triggers, admin panels, etc.), which can significantly increase the AO count. My idea is to replace most Email Web Screens with an Extension-based approach. Instead of building multiple Web Screens for email management, we can: Handle email generation, templates, and logic inside an Extension Store email templates and configurations in the database Trigger emails via server actions or APIs without requiring dedicated UI screens How this helps customers: ✅ Reduces AO consumption by eliminating multiple Email Web Screens ✅ Lowers licensing cost for large-scale applications ✅ Centralized email logic in one reusable Extension ✅ Better performance and maintainability for complex email workflows ✅ Reusable across multiple modules and applications Example Use Cases: Transactional emails (OTP, notifications, approvals) Bulk marketing or system alerts Multi-tenant email templates per client Configurable email rules without UI-heavy admin screens This approach can help enterprises optimize licensing cost while still keeping email functionality flexible and scalable.