Since OutSystems recommends a separation of deployment and release by using Feature Toggles, I think it makes sense for this feature to be available in the unified ODC Portal and more integrated with the deployment process.

Service Studio is supposed to be a WYSIWYG IDE. However, when working with things displayed in conditional situations, the layouts tend to shrink, resize, warp, or whatever else, breaking the preview. Example: This search with filters section is something very common to be found in many apps. This is a screenshot from the preview in Service Studio, and matches exactly what renders on the website after publishing. However a requirement came up to hide the bottom two under a role check, wrapping them in an If to only display them if they come up True: If published, rendered it looks fine, but the preview in Service Studio breaks There are some tricks; wrap the If in a container, put an empty container in the False branch... but those are just workarounds which shouldn't be necessary (and sometimes, as in the screenshots, they don't work) The idea, in short, is: make Service Studio render the contents as the CSS rules say it will render, If or no If

A few months after go live, production users start complaining that they randomly lose their session in a mobile app.The conclusion from your testers is that users are logging out of a reactive web application in their desktop browsers, and 5 minutes later they lose the mobile session."IMPOSSIBLE!" - you say - "Logging out from the browser cannot possibly terminate the mobile session 5 minutes later, that's absurd and unheard of"So you try to investigate it yourself and, sure enough, the tester was right. Logging out from the desktop browser indeed terminates not only the mobile session, but every other session of the user. Oh, you also find out that this is documented and deliberate: "When the end user logs out of an application, all sessions are terminated".You investigate further, and begin to realize that it's impossible to preserve the mobile session after the user has logged out from a browser . It's also impossible for the user to use multiple browsers on different devices , or even multiple browsers on the same device, because any logout action would terminate all sessions in all browsers. This is unexpected behavior that contradicts how the web works.You reconvene with your testers to brainstorm workarounds, but you're not taken seriously: "Surely this very expensive platform and market leader can support an application running on two browsers simultaneously!" All you can do is wish it did...If this scenario has happened to you on any project, please like this idea and share with others. Together we can change how the Logout works, and enable this very basic feature which is having two independent sessions on distinct devices.

Hi,In Reactive Web Apps I've noticed that when navigating to public screens from other modules the transition is very slow - it shows a blank screen first, then it starts loading the screen and the CSS, causing a Flash of unstyled content.This takes about 2 to 4 seconds, making it a horrible experience.Upon further investigation, I've discovered that OutSystems is treating the navigation as a navigation to a totally different application, loading again all the necessary resources (JS, HTML, CSS). This is very atypical for a Single Page Application.This makes segregating front ends a major trade-off.Can this be improved?Thanks,Tiago

I very much liked in former times the three developer classifications: Associate Professional Expert Professional has unfortunately disappeared now. I think the personal step from Associate to Expert, when setting career goals is a big one. The range from Associate to Expert is too big. I would very much like a reviving the professional status, after the Associate classificaton when a developer obtains any three of the six required additional certifications for an OutSystems Expert to get rewarded as "OutSystems Professional Developer"

Today, when there is need to do some configuration in the destination environment of a deployment (site properties, timers, end points, etc), this configuration must be made after the deployment is done.Would be nice to have a way of preparing those configurations during the planning and see them being applied automatically during the deployment.

Currently in OutSystems, developers often need to wrap widgets inside a Container or an If widget just to control their visibility. This makes the UI tree more complex and adds unnecessary nodes. Proposed Solution Add a “Visible ” property directly on all widgets. Accepts a Boolean expression No need to wrap the widget inside Containers or If widgets Works for all widget types (Text, Input, Button, List, etc.) Automatically hides/shows the widget based on the expression Example Visible : User.IsAdmin = True The widget is only visible if the expression is true — without adding a Container.

Currently, if we define a Sorting by an attribute, that sorting becomes unresponsive after introducing a Group By in the aggregate, as the sorted attribute is no longer part of the aggregate output . This does not raise any errors or warnings in the TrueChange Tab or any signaling in the workspace. I find that this is an easily overlooked situation that can lead to unexpected behavior or inconsistent results. I suggest the implementation of a typical Outsystems background validation that triggers a warning (written on the TrueChange Tab and a visual cue on the aggregate) whenever the aggregate's sorting references attributes that are not part of the aggregate output after a Group By, ensuring consistency and preventing silent issues.

💡 A new input parameter, (defaulted to false obviously,) to REST calls called " ContinueOnError ", which causes the rest method to return successfully, but with 3 additional fields (or even a structure) returned with " Success ", " HTTPResponseCode " and " TextContent " fields. 📉 Some REST APIs return " failure " HTTP Response Codes for valid responses, such as " 404 Not Found " if the record doesn't exist. (Lets ignore the debate about using 404 for record not found *AND* page not found.) 🕞 In the context, this may not be an a error, but it's going to end up in the generic error handler where you are going to be parsing the text of the error message to try to see what actually went wrong, and possibly displaying a load of technical junk to the user. 📜 Even within a single error code, there could me a range of causes, with the details being in the response as JSON. 🔍 Now obviously , I know you can do all this with code in OnAfterResponse , but you can't set that on a API method level, only on the connection , so you're going to have some pretty ugly code in OnAfterRespose to work out which API of ten calls you made and whether it's really an error. 🎯 I suggest it would be far better to have an option to allow the API call to continue to the next step in the procedure, then check the response to see if it succeeded, and work out if we need to raise an error, retry, or just continue, based on the response. Edit to add: This doesn't seem like it should be particularly hard to implement. Edit to also add: Added icons because everyone else uses them

I am suggesting the addition of an IsAsynchronous parameter ( non-mandatory, set to False by default ) on the Refresh Data UI Flow Screen action, to tell the Refresh Data block to run the given Data Source in either an asynchronous or synchronous way, depending on the value of that input. This will spare the work of creating dedicated screen actions to refresh the Data Sources separately in a Screen Action to conceive a pure asynchronous Data Source Refresh, when applicable. Best regards!