With the creation of this new feature of disabling elements in the action flows, "garbage" of unused logic can be accumulated in a fast way. If it was possible to find these disabled elements in a fast way, it could be very useful in my opinion.

It would be great if OutSystems could collaborate with partner companies to offer internship opportunities for newcomers in the community. While the OutSystems Developer School already helps many beginners learn the platform, having a structured internship program would give them valuable real-world experience and a chance to apply their knowledge in live projects. Through this initiative, OutSystems could also recommend top-performing learners or certified developers to partner companies, helping new talents get recognized and boosting their confidence to grow further in their OutSystems careers.

To keep the code cleaner and avoid circular dependencies, it would be interesting not to let a module publish when you had to create circular dependencies.

like to see service studio having a inbuild animated icons like animated SVGs

Scheduled deployment is a smarter, more efficient alternative to manually clicking the deploy button. By automating and scheduling deployments, organizations can improve consistency, reduce errors, and optimize resource usage. Adopting scheduled deployment as part of a robust CI/CD pipeline ensures smoother, more reliable software releases, ultimately leading to better operational efficiency and user experience. Benefits of Scheduled Deployment 1. Reduces Human Error Manual deployments rely on human intervention, increasing the risk of mistakes, such as deploying the wrong version or skipping a critical step. Scheduled deployment eliminates this risk by automating the process. 2. Ensures Consistency and Reliability With manual deployment, inconsistencies can arise due to variations in execution. Scheduled deployments follow the same automated process every time, ensuring reliability across different releases. 3. Optimized for Off-Peak Hours By scheduling deployments during low-traffic periods (e.g., midnight or early morning), teams can minimize disruptions to users and reduce the risk of downtime. 4. Frees Up Developer and Operations Teams Developers and DevOps engineers no longer need to be present at odd hours to manually deploy updates. Instead, they can focus on more critical tasks while the deployment occurs automatically. 5. Enables Continuous Deployment (CD) Scheduled deployment is a key component of Continuous Deployment (CD), allowing teams to release updates frequently without manual intervention. This results in faster iteration cycles and quicker time-to-market for new features. 6. Supports Rollback and Disaster Recovery With automated deployment, rollback strategies can be implemented to quickly revert changes in case of failure. This ensures better disaster recovery and system stability.

Service Studio prevents creating foreign keys that reference a static entity defined in a Library module.This makes sense for Protect and Delete rules, because the static entity defined in a Library module is not backed by any database tabe.However, IMO nothing is preventing us from using a foreign key with Ignore rule. These foreign keys will not have any database constraints, and will just be syntactic sugar to their underlying type (Integer, Long Integer or Text) but with the additional type checking and suggestions we come to expect from Identifier types.For example, it should be possible to define static entities that augment the capabilities of OutSystems UI by using this pattern, as described in https://medium.com/@leonardo-monteiro-fernandes/extending-static-entities-part-1-bec8b3b7631cThis would also allow values obtained from SOAP enumerates (which are mapped to non-persistent static entities) to be stored in database entities, without discarding the type information.

Hi everyone, I would like to propose the creation of an official training path and a specialization certification focused on Digital Accessibility, covering both OutSystems 11 and OutSystems Developer Cloud (ODC). As Low-Code developers, we have the responsibility to ensure that applications are inclusive by deeply applying WCAG standards within Service Studio and ODC Studio. My suggestion is for OutSystems to offer: Accessibility Guided Path: A comprehensive training focused on using OutSystems UI accessibly, handling ARIA roles, managing focus, keyboard navigation, and testing with screen readers. Specialization Exam: A technical validation for developers who have mastered the implementation of accessible interfaces in Reactive and ODC applications. Profile Badge: An official badge on the community profile, allowing partners and clients to easily identify developers capable of delivering high-quality, inclusive projects. Why is this important? Market Differentiation: Accessibility-certified professionals are rare and highly valued by large enterprises. Product Quality: It reduces technical debt and ensures that "High Performance Low-Code" also means "High Inclusion." Platform Strength: It demonstrates that OutSystems leads the market not only in speed but also in social and technical responsibility. I believe an "Accessibility Specialist" badge would elevate the technical level of our community and help build a digital world for everyone. #Accessibility #Certification

Hello, It would be very useful to Add applications to deployment plan and be able filter by them by team. In a large factory with hundreds of applications it gets hard to select the right applications to add the the plan, even using naming conventions. Having this optional filter would ease up this task when you have well segmented teams corresponding to each architecture business domain.

Self-quarantine is a very important part of journey to deal with Corona Virus. There can be instances where  people in self quarantine might need help with basics around household stuff, groceries etc. which they cannot step out to get. A portal where patients can post for help and then people in the vicinity can offer for help. Then based on the responses the patient can choose any one to help and provide additional details like address , contact details as required.

We are trying to use a Bedrock Inference Profile instead of specifying the foundational model ID directly. Our goal is to track Bedrock model usage via AWS cost allocation tags. However, when we use an inference profile ARN instead of a model ID, we get the following error: Couldn't establish a connection to the provider Endpoint 'arn:aws:bedrock:us-east-1::application-inference-profile/' failed to establish the connection with the provider. Error code: 404 Error message: BedrockException - Bedrock Invoke HTTPX: Unknown provider=None, model=arn:aws:bedrock:us-east-1::application-inference-profile/. Try calling via converse route - `bedrock/converse/`.. (OS-ABPS-40009) We ran into a similar issue with LangChain, which we resolved by explicitly passing a provider parameter. In LangChain, provider is optional because it can be inferred from the model ID or ARN, but when using an inference profile ARN, the provider information cannot be derived from the ARN alone, so it must be supplied explicitly. We suspect the same root cause applies in ODC, but ODC does not appear to expose an option to specify the model provider. I suggest to add this feature in ODC.