Excellent. Thank you for looking into that. We will continue to test here. Good to know we have two paths.

Oh 100% @Cipherali. I filed this Feedback and I am an MDM/Declarative vendor. We have had both EDU and Internal IT customers ask for this as well as MSPs. I always encourage the admin users to file their own Feedback too. These pain points will only get better if we all explain the use case on the admin side and end user side so that the Declarative management framework can be built on and the right functionality implemented.

Sounds good. Will do. Will put a Feedback in for allowing for non OS updates use in the Enforcement Specific similar to how ProductKey is used for full OS updates. Thanks!

I filled FB18116703 - Allow for some type of enforcement window or maintenance window for when AutomaticActionsObject is set with SoftwareUpdateSettings about this last year. The idea being this could solve the pain point with SoftwareUpdateEnforcementSpecific that leads to a few outcomes: 1.) The end user of the device does not see the Notification Center alert (I know we all read all Notification Center alerts but less technical or distracted end users might miss it) for the coming PAST DUE installation since the TargetLocalDateTime has long passed and the device reboots at the 60 min. PAST DUE deadline in the middle of a Zoom call or some other bit of work for the end user. 2.) The device admin might remove the SoftwareUpdateEnforcementSpecific from the device and try and re-apply it later, but if they do not remember that the device then ends up NOT updated and complaint with patches. 3.) The admin might opt for the more graceful SoftwareUpdateSettings Global Settings Declaration to install updates, but if the user's device is always offline at non-work work hours or other situations it can lead to a longer window if not a forever window of time where the update is not installed on the device. What I was suggesting was an ability to invoke the conditions (as much as possible) or rather calculation that the AutomaticActionsObject kicks off with the device side machine learning auto install action. Ideally that would be a predicate or some service activation device side that takes place in a window of days AFTER the Major, Minor, or System Deferral window. EX: Deferral is 14 days, then a 7 day kicked up AutomaticActionsObject install window, with an other 7 days where the device will attempt to install and will treat the update more like a SoftwareUpdateEnforcementSpecific PAST DUE with a 60 min. countdown that shows in Notification Center loudly over DnD. This enforcement window or maintenance window could also solve another issue for NON-OS Updates like I posted about here in this Live Q&A. We also use use the now removed in OS 27+ ScheduleOSUpdateScanCommand, AvailableOSUpdatesCommand, ScheduleOSUpdateCommand, and OSUpdateStatusCommand in some workflows where updates are set to happen with the install and force reboot asap while the admin watches the install happen live in the admin UI per device, not at a time in the future like SoftwareUpdateEnforcementSpecific and SoftwareUpdateSettings with booking updates at a future date and time or X number of days after the release and a deferral period. With an enforcement window or maintenance window we could still provide that level of functionality with a trigger to invoke that winnow. Plus; XProtect, Safari, and other non OS updates would then be possible still post MDM Updates depreciation. This is important for us since the SoftwareUpdateEnforcementSpecific Declaration only has the TargetBuildVersion use case as far as the documentation calls out today. We are interpreting that as it would not be able to be used for Safari updates and the like on macOS. Today we use the ScheduleOSUpdateScanCommand, AvailableOSUpdatesCommand, ScheduleOSUpdateCommand, and OSUpdateStatusCommand in a different CRON job workflow for that use case so that admins can book and schedule time windows that those NON-OS updates take place.