Comments
Strongly support this idea.As a global ISV, we often need to expose country-specific or customer-specific fields through standard APIs. Today, even a single additional field requires copying and maintaining the entire API object.This leads to duplicate code, higher maintenance costs, complex upgrades, and fragmented API implementations across localizations.API extensibility, similar to Table Extensions and Page Extensions, would be a major improvement for partners building scalable international solutions and would significantly reduce technical debt across the ecosystem.
The solution has been found by our own scripting. It would still be nice to have an official tool for this.We handle it with an Azure Automation runbook (PowerShell) that talks to the BC Admin Center API using an Entra app registration with Automation.ReadWrite.All consented across our tenants. It runs daily: for every environment with a pending update, it computes a target date and writes it back via the API's update-scheduling endpoint.The core rule is phased — sandboxes are always scheduled ahead of production, giving a validation window before the live environment moves. The runbook only touches dates Microsoft auto-assigned; anything a human deliberately picked is detected and left alone, and it never lets a production run ahead of its own sandboxes.