It seems as though the option of reboot if required under patch policies is not working correctly. There are instances where the service installs a patch or a 3rd party update to a product that I know for sure does not require a reboot but the machine will still reboot.

Also, is there a way to split out the 3rd party patching from the windows updates? We have users that miss patching windows and it forces their machine to reboot multiple times. One for windows updates and another for 3rd party even though it is not required.

Why would the system not install both windows updates and 3rd party patching if both are needed and then do 1 reboot IF REQUIRED?

I don't have an official answer for this, but honestly I think your idea of how patch management works is a bit off.  You understand that Windows doing updates, often times requires a reboot before it can move onto the next patch/update, which may also require a reboot.  So in general, even with other RMMs I've worked with, will install updates and reboot more than once if required all within the allowed patch window specified in the policy. 

I understand how patching works. The problem is that a reboot is taking place more than once when it does not need to. I have checked many systems and patches that do not require reboot based on the catalog are still getting flagged with a reboot. Same thing with 3rd party patches. Most software updates do not need a reboot anymore and have personally verified this.

My issue with the whole thing is the verbiage. The check box states "Reboot IF REQUIRED" which is not accurate to what it is doing. It seems to reboot no matter what if there are patches installed; then reboots again if any 3rd party patches are installed. Usually this would be fine, but for machines that miss the patching window, it causes the machine to reboot multiple times and does not allow an option to schedule/delay or anything; causing user interruption when majority of the office is using laptops. Even just an option to reboot all at once, vs a reboot for patching and then another for 3rd party patching.

My work around was to attempt to do 3rd party patching at a different time, but this is not possible.

I haven't experience these issues personally, but the only other thing I can offer as a possible solution than, is to tell your patch policy to NOT reboot anything, and then schedule a job/task on a recurring schedule to reboot the devices at a specific time.