To prevent the solution publish from failing (concurrent module publishing); cancel the publishing module in ServiceStudio with an error.

Currently OutSystems tries to send failed emails for 2 days.  This period isn't sufficient, particularly where an email failure occurs at the start of the weekend.  Can we have a feature in factory config or in Service Centre, that allows us to extend this period?

Problem: Currently AI Mentor Studio does not seem to make a distinction between hard and soft dependencies between modules/applications. E.g. if application A has a hard/soft dependency towards application B and application B has a soft dependency to application A, AI Mentor Studio rates that as a circular dependency and with the same weight as for hard dependencies between modules. Idea: Have AI Mentor Studio differentiate the two and mark soft circular dependencies as such, but do not penalize (heavily) in comparison to hard dependencies.

It would be great to have all validation errors in one screen, because when we have deploy with to many applications, we must open the details one by one to see whick module is outdated, and the page scrolls up every time afte close detail window, making the process to slow.If we could have all this errors grouped in only one screen, or in one section or something like that, to check all the problems together

It would be nice to have a guided path on the Learn site to help you in preparing for the Profession and Expert developer exam

 Problem Description When working on complex action flows in Service Studio, it’s often hard to visually identify the main path, the sequence that runs when everything goes right and no exceptions are thrown. Once an action starts to grow with multiple if nodes, exception handlers, and different branches, all the lines look the same. This makes it difficult to quickly understand: Which path is actually executed most of the time Where to safely add new logic Where performance-heavy steps should go How the flow is intended to run under normal conditions This becomes even more confusing when maintaining someone else’s work or revisiting a module after a long time. Idea / Proposed Solution It would be extremely helpful if Service Studio allowed us to highlight or mark the main execution path inside an action flow. Some possibilities: Manually select certain steps and mark them as the “main flow,” so they get a subtle color or visual emphasis Dim non-main branches for easier reading Add a toggle to show/hide highlighted paths Or even allow Studio to auto-suggest a main path based on the straight-through execution sequence Even a small visual cue would make a big difference when reading or designing large flows. I believe this small enhancement would significantly improve the experience of working with complex action flows, especially in enterprise-scale applications.

I commonly use a Boolean variable input into blocks to trigger a block refresh for React apps. Since the variable isn't explicitly used in the block I'm stuck with a warning on the variable. If a block has an OnParameterChange action it seems like that should clear any unused input variable warnings. Because they're being used.

Given GDPR constraints and consideration, it would be great that Outsystems could support this natively.This could be done in a way that entity attributes could be marked as sensitive data (works for GDPR and other data protection requirements) and additionally set a list of roles that could access them (kind of while list roles, or ACL - Access Control List - roles).Attribute would be presented (or made available) if requesting user has a granted role and if not a specific tag would be presented, e.g. "<protected>" (to distinguish between protected data from empty/null data).Note that attribute would not need to be encryted on the DB, that would easily allow for searches.To sum up, requirement is to rapidly and with low (to none) code be able to restrict access to sensitive data, out of the box.

The ossys_espace_reference table does not contain the usages of entity actions which is fine for OSUSR tables as long as you have a properly encapsulated code but since there are System entities which are not exposed with read only, it's common to have direct usages of the entity actions which are not findable. (ex.: entity action CreateOrUpdateUser of entity User produced by module ServiceCenter).So my suggestion is for Outsystems to please add these references to the ossys_espace_reference table or on a future platform server version rollout expose the system entities with read only and replace all consumptions by new server actions which encapsulate them.Thanks in advance

It would be nice to export the entity diagram as an image.