A "GetMonthLastDay()" function that receives as input a specific date and retrieves as output the last day of the month provided (i.e. 28, 29, 30, 31). Something similar to this: This can be very helpful when handling custom date widgets with no day to choose and you still want to filter the range from day 1 of a month to the last day of some future month. Also useful when you want to know if some date belongs to a leap year (or not).

It would be great if OutSystems could provide its own AI solution, similar to Neo, to help developers implement AI-driven features securely within the platform. Relying on third-party AI integrations often raises concerns about data privacy and security. By offering a native OutSystems AI, customers would gain greater confidence that their data remains protected while still benefiting from AI capabilities such as automation, prediction, and chat-based assistance all managed securely within the OutSystems ecosystem.

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.

Every once and a while, one needs to perform bulk operations on data, and to get the best performance reccurs to advanced queries. The thing is that these widgets aren't "designed" for this ops (one has to always insert output parameter, when no parameter is required on these cases), so my suggestion is : Create some new built-in widgets for this ops. Best Regards, Diogo C S Cordeiro

 Problem Statement In ODC, a Client Secret is required in virtually every scenario where an app communicates with external systems or calls ODC Management APIs programmatically: UsersManagement (Forge) → ODC User & Access Management API External IdP integration (OIDC) → Azure AD, Okta, etc. ODC REST API calls → Portfolio API, and others External service integrations → Salesforce, MS Graph, etc. The current behavior is that Client Secrets expire every 90 days by default (maximum 2 years), and renewal is only possible manually through the ODC Portal. Root Cause of the Issue This is not merely an inconvenience — it is a structural constraint that breaks the promise of full automation in ODC-based services. Here is why: ① No programmatic renewal path exists There is currently no Management API endpoint to rotate or renew a Client Secret. This means that no matter how well-automated your app logic is (e.g., a Timer-based user management flow), the secret renewal step always requires direct developer intervention. ② Expiry creates operational risk at scale In production SaaS or B2C environments running on ODC, a missed secret expiry means: All features depending on that secret stop working silently or with cryptic errors End-users are impacted before the team is even aware Recovery requires Portal access by a developer with the right permissions — not something an end-user Admin can resolve ③ The expiry cycle creates recurring developer toil Even with the maximum 2-year expiry configured, and even with calendar reminders or monitoring in place, this is manual, recurring, high-risk maintenance. It runs counter to the Low-Code philosophy of ODC: reducing developer toil and enabling reliable, autonomous operation. Requested Feature(s) Please implement one or more of the following: Option A — Programmatic Secret Renewal via Management API Add a Management API endpoint that allows an authorized app to rotate or renew a Client Secret before expiry. This would enable a Timer-based auto-renewal flow entirely within ODC, with zero developer intervention. POST /api/v1/clients/{clientId}/secrets/rotate→ Returns: new_secret, valid_from, expires_at Option B — No-Expiry Secret Option Allow trusted, internal service accounts to opt into a non-expiring Client Secret, similar to how other platforms (e.g., Azure App Registrations, AWS IAM long-term credentials) provide this option with explicit acknowledgment of the security trade-off. Option C — Secret Rotation with Overlap Window Support a dual-secret validity window during rotation — where both the old and new secrets remain valid for a configurable overlap period (e.g., 24–72 hours). This enables zero-downtime secret rotation in production environments.

Just like the option to export/download certificates, it would be great to have the same functionality available in the Achievements section as well. The exported file will give information about all the achievements under the achievements section.

Add the possiblity to configure the Expose Read Only property when importing an external table via integration studio. This comes in handy when importing reference data tables from another system where you don't want the ability to write to the table, preventing create, update or deletes by not having those CRUD operations inside the extension module.This would mitigate data accidents by devs and truly feel like a static entity but only external.

It would be awesome if there was the possibility of Uploading & Publishing multiple modules at once through Service Center.

Sometimes you don't want to share your solution with the whole community but only with your co-workers. It would be great if we could have restricted Forge's on each account.Large customers with multiple infrastructures could use this company/private Forge to share reusable applications between their teams.

It would be nice to reorder the filters, etc. in the Aggregates view for organization purposes. Small but nice feature from simple queries.J.Ja