What OS rel. your Android fleet is running ?

We are more flexibile when it comes to software updates. We use compliance policies that block access to corporate resources if the patch level is older than 3-6 months.

We would prefer to keep software updates more restrictive, but would either have to use E-FOTA or wait for improvements to Android Enterprise. The update control via policies (SystemUpdateTypes Automatic, Windowed, Postpone) all have disadvantages in daily operation.
A SystemUpdateType would be ideal, where updates are forced but can be postponed x-times by y-hours by the user. In addition, a flag whether the download should be forced in a mobile network would be great.

jarmo_akkanen 
Even if we do not block new major releases and we do test them, we are always a little careful. Especially with new versions, bugs sometimes sneak in that weren't noticed in the beta. With Android 13, there were initially problems with the Sync Manager, which caused mail apps to stop working. (e.g. VMware Boxer)

With Android 14, payloads (e.g. restrictions) on Pixel devices no longer seem to be able to be changed. At least we have the problems with the Pixel 6a. Samsung devices do not seem to be affected.
Aren't you worried that important features or apps will no longer work reliably on a large scale if a bug in a new major release slips through testing?