Need a field in property for developer's description in those items which was taken as dependency from other modules. Because that shared module may be developed by some other developer and in this consumer module current developer can add descriptive comment - why this item is added as dependency in this module. It will help other developers to know the usages easily in future. I hope it will be the helpful and needed one.

As time goes on, the wearable device market is starting to grow. While the growth rate is modest, wearable devices are inevitably going to become an important aspect of the mobile ecosystem. Allowing OutSystems developers to target these new devices will push the apps developed with OutSystems to new heights of functionality and UX excellence.For both Apple and Google platforms, watch apps are built within regular phone apps, allowing powerful functionality within the phone app and easy access to app information and interactions through the wearable app. This approach of targeting separate hardware platforms from the same project/codebase is one of OutSystems strengths. It makes sense to continue this strategy and integrate more devices as the market evolves.There are other wearable platforms out there, but obviously it's a case of diminishing returns. I think supporting the "big two" is more than enough. Can always re-evaluate and course correct down the road, if necessary.

Hi there, So when you'll do deployments the deployment list can become quite long. Often it results in keep scrolling to top untill you'll reach that part again. This scrolling cost time, which can be improved so I'll save time for more ideas here (-: My suggestion: Would be nice if there was a Back to top icon/text I could click so it directly sends me to top of page. See attached screenshot for an impression:

 If I want to select a Structure and I had 200 entities, I need to scroll all the way down until I found the structure. It whould be great to start typing the name of the structure/entity and I get positioned on top of the structure/entity.

We should be able to see what is the environment's platform version in lifetime so we can quickly know if there is different versions being used by different environments

Now when I filter courses with same topic and I want to see insights of them, I have to do the filtering again and again, It would be nice If it was possible to open each course on new tab. Not naccesarily on click right away, but at least be able to use "open link in new tab" (this one now redirects in full catalog).

As Owner of an application I would like to ensure that no one could promote it above a certain environment (example above QA environment).

 Current State: To link a deployment key obtained from the Lifetime API with the Lifetime user interface, it is currently necessary to map the platform entity osltm_staging to retrieve the staging id. This id is then used as a parameter in the Lifetime URL, as shown below: /lifetime/Staging_Progress.aspx?StagingId= Suggestion for Improvement: I propose two possible enhancements to facilitate the process: Option A: Allow the Lifetime deployment screen to accept the deployment key directly as an input parameter. Option B: Modify the Lifetime API to include the StagingId in its response. Implementing either of these options would simplify accessing deployment information, for companies utilizing the LifetimeAPI in their internal deployment processes. While acknowledging that a fully automated CI/CD pipeline takes away the need for the Lifetime interface, integrating these features would still benefit cases where the Lifetime API is used to enhance rather than fully automate deployment processes.

At an OnPremise OutSystems infrastructure we can schedule OSPTool to publish complete factory. OSPTool.com /Publish {<osp_file>|<oap_file>} <hostname> <username> <password>    | /PublishFactory <hostname> <username> <password>In a Cloud OutSystems infrastructure this is not easily possible.It would be nice if we could schedule the publish of a complete factory or a solution.

 ProblemIn Outsystems 11, and previous versions too, everytime we build a widget that has a higher z-index relative to the page we struggle on editing the content of the page since we have another element above the normal content of that page. Today's solutionWe can wrap up each of that widgets inside an if and toggle them whenever we need to only see the page content, or other widget content. Today's solution problemWrapping each widget with an if it's a solution for that problem, but everytime we have more than one element it could be a little unproductive to toggle each of them so we could change the view. Possible future solutionSo as a possible future solution I purpouse a multilayer view builder inside Service Studio. Whenever we place an element/widget inside a page that has a different z-index or a fixed position,  it could appear an option to select which layer we want to see at that time.This way we improve the usability while building complex pages.Thank you.