In some projects and when refactoring some logic, we can leave some variables that are only assigned and never used. The idea would be to improve TrueChange to show a warning saying exactly that. "Local Variable is assigned but never used"

Hi,I would like to suggest that it might be helpful if Service Studio alerts when using preparation data on screen actions, which increases hugely the view state and it would be aligned with the performance best practices .

HiFrom my Service Studio, I can connect to different environments but once I connect to that environment, that server details stays there permanently. I would like to have an option to clear that drop down of environment names.Also once I remember password, it is saved permanently, I would like to have an option, to clear the password so that it won't show unless I want it.Thanks and Regards,Suraj Borade

When calling a service action, the platform seem to internally set a fixed 100 seconds timeout on the request, so if the action takes longer then that, a "time out" exception is raised on the "Client side" but the action will keep running on the "server side".I'm not sure if i'm missing a setting here, but in case i'm not, my suggestion would be to either raise the 100 seconds timeout or make it configurable when calling service actions.

It is just a minor issue but it happens that I want to change the order of the variables in an Assign.

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).

My idea is to have a Mentor (AI assistent) inside the SQL Editor in ODC/Service Studio to be able to use natural language to write SQL code. There could be an extra tab next to the current ones (SQL - Test Inputs - Test Output - Executed SQL) where you can ask Mentor to write or optimize your SQL code and set Parameters and Output Entities/Structures.

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

Add the ability to post an idea with a tag ot O11 or ODC or both with a way to filter with the same as in forums.

 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.