Hi, I'm not sure if I'm the only one experiencing this but my login in outsystems.com does not persist more than a couple of hours even if I have the "Remember me" option enabled. Furthermore, I have to type mail email every time as my browser does not offer autocomplete for the email input (this might be a separate issue). Even when I try to access documentation pages, it asks for my login. If I refresh a couple of times I can access them without session. So clearly something is very wrong with the login system in outsystems.com . Could this be improved / fixed? Thanks, Tiago

It's always a problem when users click on buttons more than once, duplicating server requests. There are solutions for both client and server-side.

When developing large applications in Reactive, it is not a good practice to have all screens in the same module, otherwise its size grows considerably, taking a lot of time to open and to deploy. In those situations, it is common to split the screens through different End-User modules.At this moment for Reactive applications, it is not possible to control the module name in the URL, without being through changing the module name. This is not ideal, because the module respects a naming convention according to the factory governance, for instance <Business Application>_<MainConcept>. Besides the name the module appears in the URL is usually lower-case whereas module names are usually camel-case.Being that said, I think it would be nice to have the possibility to define the module SEO name, just like it is done for pages in Reactive Applications. This is a feature from Traditional Web that does not exist in Reactive and it's unfortunate that one has to change the name of the module from MyApp_Support  to support , for this purpose, going against our governance and architecture naming convention.

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.

It would be incredible if we would be able to add the cache_control header in the messages we are sending to the LLMs using the new AI Workbench. This feature is available at least on Claude with more info here: https://docs.claude.com/en/docs/build-with-claude/prompt-caching This approach, and I quote, "significantly reduces processing time and costs for repetitive tasks or prompts with consistent elements." This allows companies substancial savings on token usage! Looking at the documentation they clame that this is especially useful for: Prompts with many examples Large amounts of context or background information Repetitive tasks with consistent instructions Long multi-turn conversations where I would underline the repetitive tasks, which is one of the advantages of using agentic AI, where it can call the same tools again and again, with the same system prompt. In the documentation the example they give is to cache an entire book. In our case, these could be large documents with company details, or a quite big system prompt.

Currently if you have two OutSystems applications, one that exposes a REST API method and the other that consumes the method, in the consumer application you can't see if the method was changed in the exposing application and refresh it.It would be a good idea to have a "refresh REST API" option that refreshes all the consumed methods from a REST API, like we have for SOAP services (see attached image). Also, to have a warning message in a consuming application that "method x" was changed and you need to refresh that method.For example, you have a method without input parameters that returns a list of records and you consume it in another application. If in the exposing application you add a mandatory input parameter to the method and then run the consuming application you will get an error message because your request to the service is incorrect.When you open the consuming application in Service Studio you don't get a warning that one of the consumed methods  has changed and you don't have an easy way to update that method. You have to remove it and then consume it again and for this you need to know what was changed in the method.

It would be really helpful to have an "OutSystems Agent" that has knowledge about our codebases and can answer questions, generate insights, suggest actions, etc etc. It could also be connected to app metrics so we would be do some queries like: Why is X app slow today? What changed in the last deployment? Show me all missing role checks in app X Generate sample test cases for screen / action Y and so much more

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!

As requested by OutSystems Support Team, I am creating this Idea because it's important that the build log for any compilation on mobile on ODC be similiar to what we have in O11. Today, the mobile build is a huge amount of text that can be difficult to understand what is the main reason your mobile app is not compiling. In O11, it's more easy to understand. Maybe on ODC, put the main error on the top (or at the end) of the file so the developer can easily identify the root cause of the APK/IPA being broken upon compilation.

After generating the application in the Prompt, you can keep the prompt active to add new items and also edit something that has already been created. Always leave the prompt active to request new resources or edit them, modeling them as needed.