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.

On ODC Studio when you create a new agent, there is a configuration named Call Condition. By its description and behavior it should be called Stop Condition to avoid confusion: It is already there when you open the question mark icon:

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

It does not take up any backend processing power, neither does it take up any storage space in the servers. It's all frontend. Why the cost of AO for using Local Storage?

The platform lack 3 commonly used math functions: - ceiling(decimal) - floor(decimal) - random(n, m): generates a number between n and m It would be usefull to have them built-in.

Not too long ago, we got For Each nodes to display the name of the Record List as its default label . Could we get something similar for Assign nodes with multiple assignments? Current behaviorWhen creating an Assign node with only one assignment, its default label becomes the name of the assignment.After adding 2 or more assignments, the default label changes to a generic "Assign" name. Proposed behaviorThe default name of the Assign node would be the conjunction of all common leftmost names of its assignments.If a common name cannot be resolved, then it defaults to the generic "Assign" name.Examples below: Example #1 - Common name "MyStrucutre.InnerStructure" Example #2 - Common name "MyStructure" Example #3 - No common names, defaults to generic "Assign" name RemarksThe "Assign" generic name does not add any value to the understandability of the code. Thus, any feature that attempts to display a meaningful label instead of this generic name is a valid product enhancement effort IMO.Good practices say that you should always custom-set the labels of your Assign nodes. However, as we know it, many assignments created every day by the average user are unlabeled.With the proposed behavior, developers are more likely to split big Assign nodes -- that contain assignments of different/unrelated records -- onto smaller Assign nodes (each containing values of one individual record) due to the automatic naming convention, improving code readability.