Today, when an admin schedules an environment update, the Operations list records who scheduled it, when, and for which date. Good.

But when Microsoft later reschedules that update — e.g. for capacity reasons — the new date only appears on the Environments page. Nothing is written to Operations: no record that a reschedule happened, no original date, no new date, no timestamp, no reason.

The only signal is an email to whoever was registered as notification recipient at that moment. That doesn't help if the list wasn't maintained, the mail went to an unmonitored mailbox, or the responsible person took over the tenant later. The information cannot be reconstructed afterwards, because it exists nowhere else.

Update windows are coordinated with customers weeks ahead — downtime, test runs, ISV dependencies, month-end and year-end freeze periods. A silent date shift breaks that planning, and partners managing dozens of tenants cannot detect it by manually comparing environment pages against their own notes.

Request

- Write an Operations entry for every change to an update schedule, including Microsoft-initiated reschedules.

- Include previous date, new date, timestamp, initiator (admin or Microsoft service), and a reason code.

- Make it persistent and readable retroactively, independent of the notification-recipient setting.

- Expose it via the Admin Center API for portfolio-wide monitoring.

If scheduling is logged, rescheduling should be too. This closes a real transparency and auditability gap with minimal effort.